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Preface 


Modern history began with independent, often warring, tribes. Each tribe had 
their own language and culture and had achieved self sufficiency through 
incorporation of all major skills in their own society. Although self sufficient, not all 
tribes had similar access to natural resources. Thus, trading emerged as an 
important part of early civilizations. 

With basic trading in place, increased specialization occurred. Different cultures 
specialized in different types of high quality goods, and classical bartering was 
replaced by trading based on established monetary systems. To avoid conflict 
among tribes, national legislation and international treaties were established. 
Libraries and the invention of the printing press allowed for rapid spread of news 
and knowledge, ultimately fueling technological innovation. All of these 
advancements lead us to today’s interconnected, digitized societies where 
collaboration towards common objectives is the norm rather than the exception. 

There are striking analogies between the historical evolution of our industrialized 
world and the challenges facing modern enterprises. Many enterprises are still 
“tribal” in nature, in that they have not yet established common languages and 
landscapes (maps). In addition, many of the enterprise tribes do not have 
visibility to other parts of the enterprise nor, in many cases, do they care. 
Libraries are not established and processes are not defined or digitized. 
Knowledge is not analyzed to support innovation, and cross domain collaboration 
is the exception rather than the rule. We could carry on with this analogy. Suffice 
it to say that to realize better business outcomes, an enterprise needs to 
transform itself from a tribal society to a modern nation, in years not centuries. 
How do we accelerate that process? 

This IBM® Redbooks® publication provides guidance on how to combine 
business process management (BPM) and Enterprise Architecture (EA) for 
better business outcomes. This book provides a unique synergistic approach to 
BPM and EA, based on a firm understanding of the life cycles of the enterprise 
and the establishment of appropriate collaboration and governance processes. 
When executed together, BPM provides the business context, understanding, 
and metrics, and EA provides the discipline to translate business vision and 
strategy into architectural change. Both are, in fact, needed for sustainable 
continuous improvement. 

The intent of this book is to provide thought leadership and direction on the topic 
of BPM and EA synergies. Although technical in nature, it is not a typical IBM 
Redbooks publication. The book provides guidance and direction on how to 
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collaborate effectively across tribal boundaries rather than technical details about 
IBM software products. 

This book includes the following parts: 

► Part 1 , “Better business outcomes” on page 1 focuses on the value of direct 
collaboration across BPM and EA boundaries and describes the principles for 
aligning and interconnecting BPM and EA from a business perspective. 

► Part 2, “From tribes to nations” on page 51 focuses on how to achieve the 
BPM and EA synergies in practice by transforming the enterprise landscape 
from a set of independent tribes to a collaborating and coherent inter- and 
intra-enterprise network. 

► Part 3, “A worked example” on page 1 1 9 contains a fictitious example of how 
to apply the principles and practices described in parts 1 and 2 in practice. 

The primary audience for this book is leaders and architects who need to 
understand how to effectively combine BPM and EA to drive, as a key 
differentiator, continuous improvement and transformational change with 
enterprise scope. 


The team who wrote this book 

This book was produced by a team of specialists from around the world working 
at the International Technical Support Organization (ITSO). 

Claus T. Jensen is an IBM Senior Technical Staff Member in the US. He is part 
of the BPO Foundation team and is Chief Architect for SOA-BPM-EA technical 
strategy, driving their alignment and integration both conceptually and practically. 
Claus has 1 2 years of experience with SOA, BPM, and EA. Prior to joining IBM in 
March 2008, he was Group Chief Architect, VP of Architecture and Business 
Development, in Danske Bank, a regional European bank, where one of his 
responsibilities was driving Danske Bank’s SOA initiative and SOA center of 
excellence since its inception in 1999. Claus holds a PhD in Computer Science 
from Aarhus University, Denmark. He has written extensively on various 
modeling and architecture topics within his areas of expertise. 

Owen Cline is a member of the IBM Software Services for WebSphere® team 
based in San Diego, CA. He has over 20 years of experience in the software 
development field. He holds four software patents, has written several IBM 
Redbooks publications, and has presented at multiple technical conferences. For 
the past five years, Owen has specialized in SOA and J2EE architecture, 
application development, and deployment, with an emphasis on the WebSphere 
platform. In addition, he has also worked on many high profile websites over the 
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past few years. Owen earned a Bachelor of Science degree in computer science 
from the University of Pittsburgh and a Master of Science degree from San Diego 
State University. 

Martin Owen is worldwide product manager for Enterprise Architecture at IBM 
Rational®. He has over 20 years of experience in the Enterprise Architecture and 
Business Process Analysis field. He has worked at IBM since 2008 and joined 
IBM through the acquisition of Telelogic, where he was Vice President of product 
management for Enterprise Architecture. Prior to Telelogic, Martin was head of 
EMEA consulting for Popkin Software, a founder of Enterprise Architecture 
tooling with System Architect. His areas of expertise include The Open Group 
Architecture Framework (TOGAF), Business Process Modeling Notation 
(BPMN), and Strategic Planning. He was co-author of the original BPMN. Martin 
studied for a masters degree in Information Technology at Liverpool University in 
the UK. 


Now you can become a published author, too! 

Here’s an opportunity to spotlight your skills, grow your career, and become a 
published author — all at the same time! Join an ITSO residency project and help 
write a book in your area of expertise, while honing your experience using 
leading-edge technologies. Your efforts will help to increase product acceptance 
and customer satisfaction, as you expand your network of technical contacts and 
relationships. Residencies run from two to six weeks in length, and you can 
participate either in person or as a remote resident working from your home 
base. 

Find out more about the residency program, browse the residency index, and 
apply online at: 

i bin . com/redbooks/res i denci es . html 
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Comments welcome 


Your comments are important to us! 

We want our books to be as helpful as possible. Send us your comments about 
this book or other IBM Redbooks publications in one of the following ways: 

► Use the online Contact us review Redbooks form found at: 
ibm.com/redbooks 

► Send your comments in an email to: 
redbooksQus . i bm.com 

► Mail your comments to: 

IBM Corporation, International Technical Support Organization 
Dept. HYTD Mail Station P099 
2455 South Road 
Poughkeepsie, NY 12601-5400 

Stay connected to IBM Redbooks publications 

► Find us on Facebook: 
http://www.facebook.com/IBMRedbooks 

► Follow us on Twitter: 
http://twitter.com/ibmredbooks 

► Look for us on Linkedln: 

http : //www. 1 inkedin.com/groups?home=&gid=2 130806 

► Explore new Redbooks publications, residencies, and workshops with the 
IBM Redbooks weekly newsletter: 

https : //www. redbooks . i bm.com/Redbooks . nsf /subscri be?OpenForm 

► Stay current on recent Redbooks publications with RSS Feeds: 
http : //www . redbooks . i bm . com/rss . html 
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Part 1 


Better business 
outcomes 


Planning for change is a necessity for most modern enterprises, yet plans that 
are never executed have little value. Continuous business performance 
improvement is derived from proper coordination between planning and 
execution. This coordination in turn requires a firm understanding of the life 
cycles of the enterprise, and the establishment of appropriate collaboration and 
governance processes. 

Business process management (BPM) and Enterprise Architecture (EA) each 
have value on their own, they are also naturally synergistic and best when done 
together for better business outcomes and strategic alignment of business and 
IT. When done together, BPM provides the business context, understanding and 
metrics, and EA provides the discipline for translating business vision and 
strategy into architectural change. Both are, in fact, needed for sustainable, 
continuous improvement. 


Important: This book distinguishes between Enterprise Architecture (mixed 
case), or the acronym EA, as a discipline and an enterprise architecture 
(lowercase) as a construct. 
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Part 1 of this book focuses on the value of direct collaboration across BPM and 
EA boundaries and describes the principles for aligning and interconnecting BPM 
and EA from a business perspective. The primary audience for this part is 
leaders and architects who need to understand how to effectively combine BPM 
and EA as a key differentiator for successful enterprises in their drive toward 
continuous business improvement. 


2 Combining BPM and EA for Better Business Outcomes 



1 


Coordinating planning and 
delivery 


The best plans in the world have little value if they are never executed. This 
chapter explains how to coordinate planning and delivery life cycles throughout 
the landscape of a modern enterprise. 
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3 




1.1 The imperative for business agility 


In today’s business environment, Chief Information Officers (CIOs) and Chief 
Executive Officers (CEOs) are often focused on how to accomplish agile change 
and innovation. In fact, organizational, business process, IT, and many other 
types of changes are at the forefront of any discussion about how to succeed in 
the post-recession landscape. In a recent IBM survey, 8 out of 10 CEOs said that 
their organizations were facing substantial change over the next three years. This 
information indicates that many industries are reaching a process inflection point 
as the gap grows between the need for change and the ability to effect such 
change. 

Figure 1-1 illustrates this inflection point and the challenge of promoting dynamic 
growth and at the same time optimizing operational costs. 


Dynamic change 

Extensive and 

Ad-hoc, dynamic 
tasks 

inclusive business 

networks 


Social and contextual 

Business and IT 

capabilities 

9 

convergence 


Figure 1-1 Processes and information need to fuel new growth while optimizing costs 


Although agile change is a critical component of most modern enterprise 
strategies, the key is going about change in an effective and sustainable way. 
Reading recent blogs, articles, and reports, you might infer that being 
successfully agile is all about being fast, but does agile really equal fast? No, not 
at all! The underlying premise driving towards business agility is that such agility 
delivers superior business value, but what if haste to achieve agility results in low 
quality? Or, what if the speed of change is unsustainable from a business 
operational perspective, thereby leading to deteriorating efficiency? These are 
just two examples of the fundamental challenge of how doing things in haste, 
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implementing the wrong changes, or even implementing the right changes but in 
the wrong way can quickly lead to ruin. 

If your core business cannot keep up with the changes and, therefore, loses 
efficiency, if quality suffers resulting in significant loss of customers, or if you 
mortgage your company’s future by over-investing and taking too many risks, 
then what? What is the point in preparing for the future if in the process you ruin 
your current business? 

The following fundamental premises must be in place for agile change to be 
valuable over time: 

► Choose the right changes that deliver better business outcomes with the least 
amount of resources and disruption. 

► Maintain business performance and integrity while executing change. 

Agility is not really about speed but is about choosing the right changes and 
implementing those changes the right way in a timely fashion. Figure 1-2 
illustrates the need to balance efficiency and effectiveness. 



Figure 1-2 The smart enterprise balances efficiency and effectiveness for sustainable agile change 


For agile change to be sustainable, the enterprise needs to carefully plan and 
maintain an appropriate balance between effectiveness and efficiency. 
Long-term effectiveness is based on continuous business re-engineering 
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towards strategic objectives. Yet while on that strategic journey, an enterprise 
needs to continuously adjust and optimize the current state efficiency and 
ultimately maintain business integrity and performance. 


1.2 Improving business outcomes 

The IBM Smarter Planet™ initiative points out how we live in a world where 
everything is interconnected and intelligent. Agile change is becoming table 
stakes for enterprises that want to be successful. There are many approaches to 
agility, yet all of these approaches share the notion that we need to align strategy 
with execution to improve business outcomes. How difficult can that be? All we 
need to do is to create an enterprise architecture and implement the defined 
future state architecture, correct? 

In reality, there is much more to the challenge. For any architecture to be 
actionable it needs to be contextual, collaborative, connected, and consumable. 
These concepts, termed the four C’s are the foundation for architected change. 
(See 3.2, “Actionable architecture” on page 34.) To deliver tangible business 
value, we need to go beyond business and IT alignment and achieve true 
business and IT convergence, without getting stuck on “lets understand 
everything before we act.” 

Again, how difficult can it be to make an enterprise architecture actionable? We 
simply need to collaborate on that enterprise architecture, understand why we 
are creating it, and make sure to push down stream for architectural governance, 
correct? Well, yes and no. Many enterprise architects do not necessarily 
appreciate that enterprise architecture does not address how to execute change 
or how to establish the critical feedback loop that provides insight on whether the 
architecture worked as intended. To make enterprise architecture actionable, we 
need to link enterprise architecture artifacts to the solution delivery initiatives that 
actually deliver operational improvement and agile change, initiatives such as 
business process management (BPM). 

A good and scalable approach to coordinating planning and execution is to 
combine BPM and enterprise architecture. Each has value on its own. However, 
the two are also naturally synergistic, and best when done together for better 
business outcomes and strategic alignment of business and IT. When combined, 
BPM provides the business context, understanding, and metrics, and EA 
provides the discipline to translate business vision and strategy into architectural 
change. 

From an organizational perspective, the enterprise needs to engineer planning 
and delivery processes to take advantage of the synergistic powers of robust 
architectural planning (represented by EA) and agile business improvement 
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(represented by BPM). From a technological perspective, the enterprise needs to 
establish a platform that enables the appropriate collaboration by creating 
visibility, traceability, and integrity between targets and solutions throughout all 
roles and tools. Both capabilities are required components for a sustainable 
approach to agility, as illustrated by Figure 1-3. 
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Figure 1-3 Coordinate planning and delivery by combining BPM and EA 


Planning for change is a necessity for most modern enterprises, yet plans that 
are never executed have little value. Continuous business improvement is 
derived from proper coordination between planning and execution. This 
coordination requires a firm understanding of the life cycles of the enterprise and 
the establishment of appropriate collaboration and governance processes. Thus, 
optimizing business processes and solutions is no longer enough; the enterprise 
needs to optimize the process of change itself. 

It is important to realize that addressing only IT planning and execution aspects 
is not sufficient to meet these new imperatives. Changes must also occur in the 
way an enterprise approaches business planning and execution. 
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Figure 1-4 illustrates how organizations can achieve greater agility by 
strategically embedding flexibility and intelligence throughout their business. 



Figure 1-4 Take control of the business by holistically integrating processes, information, and analytics 
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By taking control of its processes and information, an enterprise can take control 
of its business through better business intelligence and improved decision 
making. 


1.3 Taking control of the enterprise landscape 

If we accept the fundamental premise that to take control of processes and 
information and to integrate planning and delivery throughout the enterprise, 
BPM and EA need to be synergistically combined, the natural question of how to 
do so effectively arises. How do you identify the most important changes, find the 
optimal time to implement those changes, and finally execute change effectively? 

Several resources address these questions, but depending on viewpoint (BPM, 
EA, business architecture, software engineering, and so on), each resource 
provides a different answer. This variety in views illustrates that different people 
have different objectives and different opinions about what constitutes effective 
changes and that most often these views are based on the discipline with which 
they themselves are most familiar. 

How do we overcome the “tribal” nature of a complex organization and evolve to 
a nation that is working together towards common goals based on each of our 
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specialties and skills when often these different enterprise “tribes” do not even 
share a common language base or the same concepts as a foundation for 
understanding? 

First, you need to establish a common and recognized landscape for change. 
Only then can you discuss how to collaborate and govern within that landscape. 
In this context, we have chosen the landscape analogy intentionally, because we 
believe that the first prerequisite for building a nation is to map and understand 
the various tribes that live within the borders of that future nation. After you know 
who is out there, and perhaps go further to understand some of their languages 
and goals, then fears and concerns are reduced and challenges are more 
tractable. You have, in fact, progressed from an unknown void to an explored and 
known landscape. Admittedly, there are still many challenges ahead on the 
journey to become a nation, but now you can identify and address these 
challenges, as opposed to simply fearing the unknown, often irrationally. 

We are not suggesting that a modern enterprise is the same as a tribal 
environment full of fears and superstitions. Still the analogy holds in that 
something known and recognized is much easier to address than something 
unknown and not recognized. With knowledge and recognition, it becomes easier 
to set up appropriate collaboration patterns to guide and govern change. 
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Returning to the notion of a common and recognized landscape for change, 
Figure 1-5 illustrates at a conceptual level the different life cycles and practices 
found in most enterprises. 



Figure 1-5 Defining the enterprise landscape 


The exact details of the actual enterprise landscape depend on the enterprise in 
question. Nevertheless, concrete practices, roles, methods, and even tools can 
be mapped to the generic landscape, which in turn then functions as the 
foundation for better understanding, desired interaction, and collaboration 
patterns. 

Concretely the generic landscape illustrates three fundamentally different life 
cycles that are asynchronously coordinated. Because these different life cycles 
have different scopes and purposes, they are not a “stack” and are not linked in 
any linear or hierarchical fashion. The differences between the extended timeline 
and enterprise perspective of a road map and the execution of a specific project 
with limited scope and deadline makes it undesirable to combine the cycles into 
one. 

As an example, consider a five-year road map for a business merger. Although 
the intended result is known, it is impractical to analyze all projects in the road 
map in solution-level detail before delivering and acting on a definition of the road 
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map itself. Similarly, for an service-oriented architecture (SOA) transformation 
road map, it is impractical to analyze the entire existing portfolio before delivering 
a single new service or solution. 

The perhaps most elusive of the three life cycles is the portfolio management and 
optimization life cycle. Often overlooked in SOA, BPM, or EA initiatives, this life 
cycle illustrates that there is a significant role played by the owners and portfolio 
managers of the current state of the enterprise and their need for continued 
efficiency and operational optimization. To be precise, this is the life cycle that is 
the efficiency counterbalance to the effectiveness drive that is provided by the 
enterprise planning life cycle. We consider the role and importance of portfolio 
management and optimization in more detail when we return to the notion of 
actionable architecture in Chapter 3, “BPM and EA synergies” on page 25. 

Two important feedback loops, illustrated by the red arrows in Figure 1-5 on 
page 1 0, are part of the generic landscape: 

► Feedback from “contract” to enterprise planning 

This feedback loop creates visibility towards the things that projects intend to 
build and whether such intent is aligned with current enterprise plans and 
blueprints. The metric for success is not related to any particular solution or 
deliverable but rather is related to the progression over time towards 
long-term enterprise objectives. 

► Feedback from operations to portfolio management and optimization 

This feedback loop provides the insight as to whether current operations meet 
defined key performance indicators (KPIs) and metrics and form the 
foundation for adjustment and optimization of the efficiency of the current 
state of the enterprise. 

Both of these feedback loops are critically important for maintaining an 
appropriate balance between long-term effectiveness and short-term efficiency 
in a rapidly changing environment. Without the feedback from operations to 
portfolio management and optimization, the enterprise is acting blindly with no 
ability to detect the operational effect of changes and the operational health of 
the enterprise. Without the feedback loop from contract to enterprise planning, 
plans quickly become stale and out of sync with reality, leading to the so called 
“ivory tower syndrome” that traditionally has hit many EA initiatives. The plans 
look good on paper, but nobody takes them seriously and they have no real 
impact on the evolution of the enterprise. 

Note that the different characteristics and purposes of these feedback loops 
speak to the differences between EA and BPM, with EA incorporating feedback 
against planned change and BPM incorporating feedback against improved 
operational efficiency. 
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2 


BPM and EA defined 


To fully understand the synergies between business process management 
(BPM) and Enterprise Architecture (EA), we need to first define each in isolation 
and understand how it is placed on the enterprise landscape. We provide 
information about these topics in this chapter. 
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2.1 The value of architecture 


Some would say that architecture is anathema to agility, citing as a reason that 
time used on architecture could be better used on agile delivery of business 
solutions. Yet how can you really take control of the enterprise landscape without 
understanding its structure? How can you empower people without defining the 
scope within which they are empowered? And how can the tribes of the 
enterprise collaborate effectively without well-defined components and 
boundaries upon which to communicate? 

Architecture in its generic meaning is simply the structure and design of a system 
or product. Architecture as a discipline analyzes a problem and decomposes that 
problem into its constituent buildings blocks. The architect role is responsible for 
the coherency and consistency of the set of buildings blocks that are applied to 
solve a problem or to build a solution. Architecture is a key enabler for doing the 
right things the right way rather than doing some (arbitrary) things quickly. The 
value of the architecture lies in the outcomes it enables, rather than the price of 
construction. 

More specifically, value of the architecture is economical, functional, and 
constructional: 

► Economical, understanding the value and interactions of business activities 

► Functional, understanding the systems (business and IT) that are required to 
support key business activities 

► Constructional, understanding the (reusable) components of which such 
systems are composed 

There is an architectural foundation for any information system; in fact, an 
information system by its nature cannot be built without some level of 
understanding of the parts of which it is composed. In the context of this book, 
the building blocks of primary interest are those common to BPM and EA, 
building blocks such as processes and information entities. Without an 
understanding of these building blocks, including how they interact across the 
three enterprise life cycles shown in Figure 1-5 on page 10, it is practically 
impossible to make the tribes of the enterprise come together as a nation. Part of 
the trading language of the enterprise must be a common understanding of 
architecture and its constituent components. 

Some types of architecture, such as enterprise architecture, help us with doing 
the right things by describing the components of the vision for tomorrow and the 
standards by which we measure ourselves. Other types of architecture, such as 
BPM solution architectures, help us do things in the right way by describing the 
components of an optimized solution and the means by which that solution 
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(when operational) is monitored and measured over time. There is no “right 
order” in which such architectures must be applied. Rather, an effective 
enterprise understands and appreciates the value of appropriately merging 
different architectural approaches. 

The remainder of this chapter focuses on understanding the approach and role of 
BPM and EA in isolation. Chapter 3, “BPM and EA synergies” on page 25, 
provides guidance about how to use them together for continuous business 
improvement. 


2.2 Business process management 

The notion of business process optimization has been around for almost a 
century and has been a key component of the industrial revolution. Yet in the last 
decade, the focus in many process improvement communities shifted subtly to 
one of BPM. The key distinction for BPM as a discipline is added focus on flexible 
and dynamic process design as well as process orchestration and automation 
through IT enablement. In addition to reduced cost through continued process 
improvement and automation, BPM also provides the foundation for converged 
and agile business and IT responsiveness. 

Figure 2-1 illustrates these concepts. 


Collaborate to predict and optimize 
process outcomes through modeling 
and simulation 

Rapidly customize processes with 
business users using policies instead 
of code 

Sense and respond to business events 
in real-time for automated response or 
human decision support 
Rapidly deploy new solutions from 
reusable building blocks that can be 
changed on-the-fly 


Business View 


Process View 



IT View 


BPM enabled by SOA 
bridges Business and IT 


Figure 2- 1 BPM drives business and IT alignment and responsiveness 


Intrinsic to BPM is the principle of continuous operational improvement, 
perpetually increasing value generation and sustaining market competitiveness 
(or dominance) of the organization. BPM focuses on driving overall bottom-line 
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success by horizontally integrating business verticals and optimizing core work 
(for example order-to-cash, integrated product development, and integrated 
supply chain), thereby directing the deployment of resources throughout the 
organization into efficient processes that create customer value. This focus 
differentiates BPM from traditional (compartmentalized) functional management 
disciplines. 

Table 2-1 defines BPM as described in the IBM white paper Leveraging SOA, 
BPM and EA for Strategic Business and IT Alignment, which is available at: 
http://www.ibm.com/developerworks/websphere/bpmjournal/0812_jensen/0812 
_jensen.html 


Table 2- 1 Definition of BPM 


Base definition 

Main value proposition 

Key results 

A solution delivery discipline, 
based on service-oriented 
architecture (SOA) practices 
that drives business agility, 
efficiency, and improvement 
around organizational 
concerns and measurable 
business objectives 

Business optimization and 
IT responsiveness using 
process definition, analysis, 
customization, and 
deployment (“The right 
organizational resources 
doing the right things”) 

► Collaboration to predict and optimize 
process outcomes and operational 
efficiency 

► Rapid deployment of new solutions 
from reusable building blocks 

► Rapid customization of flexible 
processes 

► Real-time sensing and response to 
business events providing end-to-end 
visibility and actionable insight 


BPM solutions can be delivered to the business operational environment with or 
without IT enablement, yet will always have operational efficiency as a key factor. 
The delivery of improved business processes through non-IT means, such as 
documented operational procedures, is completely analogous to the delivery of, 
for example, IT-enabled workflows. Both types of solutions are encompassed by 
the discipline of BPM. It is important to notice that BPM is squarely focused on 
solution delivery, not enterprise planning. 
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Placed on the enterprise landscape illustrated in Figure 1-5 on page 10, BPM is 
positioned as described in Figure 2-2. 



Figure 2-2 Placing BPM on the 


After a business process is deployed, it must be managed. To manage the 
business process, visibility into process performance is required. When a 
process is no longer meeting its performance goals, it is time to assess the root 
cause of the performance problem and to look for additional improvement 
opportunities, thereby triggering yet another project in the continuous process 
improvement cycle of the enterprise. 

BPM is often associated with the life cycle of a single business process, with that 
life cycle spanning from identifying and improving a process to deploying and 
managing the process when it is operational. What is often less appreciated is 
that a large scale (enterprise) BPM initiative also relies heavily on a holistic 
understanding of the portfolio of operational processes and the key metrics and 
measures that apply to that portfolio perspective. Thus, as a BPM initiative 
matures, it must reach into the portfolio management life cycle, managing both 
the initiation of and the structured harvesting from a multitude of (parallel) BPM 
projects. 
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As shown in Figure 2-2 on page 17, BPM is not enterprise planning. In fact, a 
typical BPM project is focused on nondisruptive improvement of current 
processes rather than the re-engineering of the business itself. Enterprise 
planning is the realm of EA, the definition of which is the topic of the next section. 


2.3 Enterprise Architecture 

EA as a discipline provides the foundation for an organization to align strategic 
objectives with opportunities for change. This is achieved through portfolio gap 
analysis, transition planning, and architectural governance. Table 2-2 defines EA 
as described in the IBM white paper Leveraging SOA, BPM and EA for Strategic 
Business and IT Alignment, which is available at: 

http://www.ibm.com/developerworks/websphere/bpmjournal /0812_jensen/0812 
_jensen.html 


Table 2-2 Definition of EA 


Base definition 

Main value proposition 

Key results 

An architectural 
discipline that merges 
strategic business and 
IT objectives with 
opportunities for change 
and governs the 
resulting change 
initiatives 

Driving portfolio 
planning in a strategic 
context and directing 
change toward common 
enterprise goals (“The 
right changes enacted 
the right way”) 

► Faster, better-informed strategic and tactical 
decisions with validated results 

► Prioritized investments to support business 
goals 

► Improved risk management of organizational 
transformation 

► Enterprise-level communication and visibility 
for people, processes, and assets 

► Standardization and governance of shared 
business and IT building blocks 


The resulting enterprise architecture (as a construct) is used to identify impacts 
of changes on the enterprise and to drive the gap analysis between current and 
future states. Different transition plans, which are required to move from one 
state to another, are also considered as part of enterprise architecture analysis. 
Note that such transitions can be disruptive to the current state and in general 
cannot be “implemented” through a (single) solution delivery project. 

Applying an enterprise architecture provides the following benefits: 

► The ability for an organization to make specific decisions about which future 
states to implement based on cost, resource, and architectural fit 

► Architectural direction to projects 

► A governance mechanism for IT in the adoption of new applications and 
technology, a governance mechanism based on business need and value 
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These benefits are related to enterprise planning rather than solution delivery. 

Placed on the enterprise landscape illustrated in Figure 1-5 on page 10, the EA 
discipline is positioned as shown in Figure 2-3. 



Figure 2-3 Piecing EA on the enterprise lendscepe 


Intrinsic to enterprise architecture is the notion of a “blueprint” providing a 
reusable pattern, a desired standard, or a desired future state of the enterprise, 
including the organizational structure, its supporting information systems, and 
the IT infrastructure that hosts them. As shown in Figure 2-3, EA blueprints are 
not intended to be used (directly) in a particular solution. Rather, they are applied 
as enterprise planning guidance to any solution delivery activity within their 
scope of influence. 

Typical value propositions for EA include the following concepts: 

► Creating a blueprint of enterprise information to make faster, better informed 
decisions 

► Using EA blueprints as a communication platform between business and IT to 
ensure that IT investments are in line with business needs 
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► Gaining insight into the impact that changes will have on all aspects of the 
business to better manage transformation initiatives 

► Converting business strategy and enterprise-wide processes into effective 
supporting IT technologies 

► Validating IT investments to assure alignment with business value and 
expectations 

In the sections that follow, we explore typical EA entry points as well as the EA 

frameworks that allow us to organize and use EA artifacts effectively. 


2.3.1 EA frameworks 

EA frameworks usually provide a context in which all stakeholders in an 
organization can communicate and collaborate about their enterprise 
architecture. 

EA frameworks typically support the domains of change illustrated in Figure 2-4. 



The enterprise architecture is expressed using models, which are based on a 
metamodel that defines model types and their relationships. Different EA 
frameworks have their own particular metamodel and taxonomy, but in general, 
all EA frameworks cover the domains of change shown in Figure 2-4. 
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In the industry, many different standardized EA frameworks can be used to 
represent the model of the enterprise architecture itself and the associated 
(categorization of) model views. Such frameworks include the following 
examples: 

► Department of Defense Architecture Framework (DODAF) uses defense 
taxonomy to describe the model and the model views of the architecture 

► Ministry of Defense Architecture Framework (MODAF) uses defense 
taxonomy to describe the model and the model views of the architecture 

► Archimate: An EA framework from the Open Group with explicit notation for 
model views of the architecture 

► The Open Group Architecture Framework (TOGAF): An EA framework also 
from the Open Group with a conceptual model for EA and non-prescriptive 
views 

► The Zachman Framework: An EA framework that represents a catalog of the 
model elements of EA. 

For more details about EA frameworks from an industry standards perspective, 
see Chapter 7, “The role of standards” on page 89. 

EA frameworks address both business and IT domain aspects. Business-related 
model types/views include the following examples: 

► Business Motivation Model provides a comprehensive view of the motivation 
and strategy views of the architecture. 

► Business Process Modeling Notation (BPMN) provides a common metamodel 
and notation for representing business processes. BPMN can be used in 
many different ways in the modeling landscape, including views outside of EA. 

► Entity Relationship Diagrams provide a standard view of data and 
relationships. 

► Organization Charts provide specific views on organization units and 
associated roles. 

Model views can be produced in specific visualizations for different stakeholders 
in the organization. For example, an IT director might be interested in a 
dashboard of applications, their capabilities, risks, and ongoing costs. An IT 
architect might be interested in an application portfolio model view of all of the 
applications and their associated interfaces. 


2.3.2 Entry points for EA 

Organizations that can accurately strategize, execute, and manage the impact of 
change can quickly identify risks, resource requirements and quantify their ability 
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to execute without resorting to “trial and error” mechanisms. These types of 
considerations are an important part of the strategic and IT planning functions of 
a modern enterprise. 

In a business climate where enterprises are experiencing increased competitive 
pressure and shifting market conditions, organizations that thrive have defined a 
capability and framework that allow them to act quickly and decisively. In turn, 
they can accelerate change to seize business opportunities. 

There are a number of explicit entry points for which EA can be used to solve 
particular business challenges related to planning and managing change. 

Figure 2-5 provides an overview of the most typical EA entry points. 



Figure 2-5 Typical EA entry points 


These typical EA entry points are loosely described as follows: 

► Business Efficiency or Planning allows organizations to become more 
proficient in their planning particularly around addressing specific business 
aligned issues, such as achieving a particular business goal or driving costs 
out of the operations of the organization. 

► IT planning and Optimization entry points solve IT-related issues, such as 
managing and transforming an IT portfolio. IT planning is key to ensuring that 
the IT environment is lean, responds to business needs, and is perceived as 
an enabler for the organization. 
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► ERP is usually a core business strategy and can be a major contributor to the 
IT infrastructure that an organization runs. ERP also affects the way that 
many of the business processes operate within an organization. 

► As organizations look at a wider enterprise vision of their organization, they 
typically describe a Systems of Systems vision. This vision includes suppliers, 
partners, and other channels in the enterprise ecosystem, which needs to be 
understood as a whole. 

► Service (Enterprise) Architecture addresses the challenges of the modern 
day enterprise where products or business services need to be service-aware 
and provisioned on the cloud or as part of a Software as a Service (SaaS) 
offering. The architecture needs to be represented in a way that makes 
consumption of a service uncomplicated. 

► Governance, Risk and Compliance looks at the typical issues that an 
organization faces in terms of market compliance, risk, auditing and tracking, 
and overall governance. Although many organizations try to track these often 
mandatory business controls with individual programs and initiatives, EA can 
provide additional valuable insight. 


2.4 Business process analysis 

Business analysis is typically defined as the discipline of identifying business 
needs and determining solutions to business problems . 1 What is business 
process analysis (BPA) then? Is it the discipline of identifying business process 
needs and determining solutions to business process problems? While it is 
alluring to assume so, what would that say about BPM, which incorporates the 
same kind of objectives and activities for BPM solutions? Or about EA, which 
incorporates similar analysis activities for the business architecture component of 
an enterprise architecture? 

We conjecture that despite parts of the marketplace designating BPA a discipline, 
in fact it is not. Rather, it is a set of techniques that can be applied for multiple 
purposes. Consider the following examples of BPA techniques: 

► Decide the scope of a process and its integration points (both input and 
output, whether business or IT). 

► Model the flow of a process, including identifying all of the activities within it 
and how they interoperate. 

► Analyze and assign capacity to activities and identify bottlenecks in the 
process as a whole. 


1 Defined in “From Analyst to Leader: Elevating the Role of the Business Analyst Management 
Concepts” by Kathleen B Hass, Richard Vander Horst, Kimi Ziemski, 2008. ISBN 1567262139. 
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► Refine the process or offer remediation steps to eliminate bottlenecks one by 
one. 

► Analyze and optimize resource use within each activity and across the 
process as a whole. 

These examples illustrate that at the heart of all BPA techniques is the desire to 
improve a process by understanding the activities in it, how those activities relate 
to other activities, and how activity metrics can provide insight about the process 
as a whole. 

In the context of this book, the BPA techniques can be applied within both BPM 
and EA and throughout all three life cycles of the enterprise landscape, illustrated 
in Figure 1-5 on page 10. (For an activity focused elaboration of the enterprise 
landscape, see 9.1, “Refining the enterprise landscape” on page 110.) 

► BPA techniques applied in the context of the enterprise planning life cycle 
rationalize long-term architectural objectives and desirable disruptive changes 
for process building blocks. 

► BPA techniques applied in the context of the portfolio optimization cycle 
identify operational processes that require improvement and define key 
performance indicators (KPIs) that new versions of these processes should 
fulfill. 

► BPA techniques applied in the context of a project will aid in designing an 
improved “to be” process that can be implemented by the project. 

The net of which is that business processes, whether those processes result 
from BPA activities, have different semantics within each of these three life 
cycles, even if by chance they should have the exact same flow of activities. 
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BPM and EA synergies 


Now that we have defined explicitly the disciplines of business process 
management (BPM) and Enterprise Architecture (EA), we consider in this 
chapter in more detail how to use them together for continuous business 
improvement. 
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3.1 Continuous improvement 

In a globally integrated marketplace, the ability to effectively plan and execute 
change is quickly becoming a survival skill. Historically, semi-annual or annual 
business and IT planning was the norm and projects were often driven with a 
budgeting mindset. However, as our environment becomes ever more dynamic, 
our world ever more interconnected, instrumented, and intelligent, businesses 
must now continuously improve business processes and optimize costs. 

Too often enterprises find themselves restrained in meeting these imperatives by 
lack of coordination between planning and execution. The road toward strategic 
change involves the right vision, the proper understanding of the existing 
portfolio, the ability to define and execute the right projects with the right scope, 
and finally a robust platform that ensures the integrity, reliability, and scalability of 
business processes throughout the enterprise. All these aspects need to be 
governed and managed collaboratively between those who are planning the 
future of the enterprise and those who are optimizing and managing the portfolio 
of existing processes and solutions. 

The classical value proposition of EA is centered on the translation of business 
vision and strategy into effective enterprise change by creating and 
communicating key requirements, principles, and models that describe the future 
state of the enterprise and that enable its evolution. The ability to architect the 
future of the enterprise is a hallmark of EA and is the cornerstone for 
enterprise-wide planned improvement. 

The notion of business process optimization has been around even longer than 
EA. Yet, around the same time that EA became a mainstream topic in the context 
of business and IT alignment, the focus in many process improvement 
communities shifted subtly to BPM. The key distinction for BPM as a discipline is 
added focus on flexible and dynamic process design, as well as process 
orchestration and automation through IT enablement. In addition to reduced cost 
through continued process improvement and automation, BPM also provides the 
foundation for converged and agile business and IT responsiveness. 
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As BPM and EA have evolved independently without explicit recognition of each 
other and without consideration of the need for collaboration between the two 
disciplines, historically many architects have had a hierarchical view of the 
enterprise as illustrated in Figure 3-1 . 



Typically in the context of EA, a practitioner will talk about doing transition 
planning based on the enterprise architecture, deriving change projects that in 
turn are governed according to that enterprise architecture. This view of the 
world has EA at the top of a strict hierarchy. Enterprise strategy is defined as a 
balance between business opportunities and technology constraints. Enterprise 
planning then creates the city plan for the enterprise, identifies relevant change 
initiatives, and through transition planning and architectural governance guides 
the projects executing these changes. However, projects focus on solution design 
and delivery for the intended change for which each is responsible as defined in 
their transition plan. 

Unfortunately, as indicated previously, such a hierarchical “stack” perspective on 
the relationship between EA and BPM is overly simplistic and not conducive to 
appropriate collaboration between planning and delivery. Typically, such a view 
either leads to disregard for operational efficiency (and ultimately the ruin of the 
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enterprise) or alternatively to the irrelevance of the EA function (the “ivory tower 
syndrome”). 

In most cases, continuous business improvement cannot happen without 
effectively merging the holistic planning aspects of EA with the process 
improvement focus of BPM. We need to work smarter throughout the enterprise, 
transforming organizations so that people can make more informed decisions, 
build deeper relationships, and work with more agile and efficient business 
processes. 

Working smarter, however, requires more than simple alignment of efforts; it 
requires a deep understanding of the business processes of the enterprise and 
the ability to execute change on these processes by collaboration between 
business and IT. This meld of planning and delivery is exactly where BPM and 
EA are strong when done together, as illustrated in Figure 3-2. 



EA gaining additional benefits from BPM 

Consume architectural considerations into BPM 
solution delivery, enable reuse and IT governance. 

• Provide corporate approved templates and 
blueprints to govern and facilitate BPM 
business process design. 

• Optimize and deploy process models for 
maximized business outcome. 

• Publish updated process for corporate re-use 
and IT governance. 



BPM gaining additional benefits from EA 

Reference business processes for enterprise 
architecture analysis and blueprint design. 

• Analyze business processes to verify optimal 
IT implementation (data, applications, 
processes, systems, and technology). 

• Examine the impact of utilizing processes intra- 
and inter- company. 

• Validate against other corporate solution 
delivery approaches. 


Figure 3-2 Integrated planning and delivery with BPM and EA 


From an EA perspective, in one direction, establishment of the proper business 
context is a prerequisite for effective planning of architectural change - a 
business context which naturally includes BPM artifacts and metrics. In the other 
direction, BPM projects are governed and guided by architectural considerations 
and targets, which can be provided naturally by EA. 

From a BPM perspective, in one direction, process change can lead to the need 
for IT architecture change, which can be driven naturally by EA. In the other 
direction, EA can reference business processes for architectural analysis and 
design - business processes which are naturally provided by BPM. 
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Furthermore, by adding service-oriented architecture (SOA) to the mix, it is 
possible to realize additional synergies. The value proposition of SOA is centered 
on agile and aligned business and IT design and delivery. The ability to architect 
the alignment between business and IT is a hallmark of SOA, and is the 
cornerstone for derived business agility, reduction of cost and risk, as well as 
improved portfolio management. Consequently SOA as an architectural style is 
well suited for modern EA. Furthermore, SOA provides horizontal transactional 
strength to a BPM initiative, thereby enabling business integrity and operational 
excellence. 


Additional resources: For more information about SOA as a foundation for 
BPM and EA, see the following resources: 

► The IBM white paper Leveraging SOA, BPM and EA for Strategic Business 
and IT Alignment, which is available at: 

http://www.ibm.com/developerworks/websphere/bpmjournal /0812_jense 
n/0812_jensen.html 

► The IBM white paper Achieving business agility with BPM and SOA 
together: Smart work in the smart enterprise, which is available for 
download at: 

ftp : //publ ic.dhe.ibm.com/common/ssi/ecm/en/wswl4078usen/WSW14078U 
SEN. PDF 

► The IBM white paper BPM and SOA require robust and scalable 
information systems: Smart work in the smart enterprise, which is available 
for download at: 

ftp://public.dhe.ibm.com/common/ssi/ecm/en/wswl4104usen/WSW14104U 
SEN. PDF 


These synergies are enabled by appropriate collaboration and governance 
processes that must coordinate plans and solutions without hampering 
effectiveness by requiring overly detailed synchronization. As indicated 
previously, we must optimize the process of change itself. In that context, the 
prerequisite for proper collaboration and governance is that we first understand 
the placement of BPM and EA on the enterprise landscape. We have already 
defined the placement of each in isolation. Now we combine the two as shown in 
Figure 3-3 on page 30. 
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Figure 3-3 Placing EA and BPM together on the enterprise landscape 


As shown in Figure 3-3, the EA focus on identifying and governing long-term 
change fits nicely into the enterprise planning life cycle. The BPM focus on 
optimizing the portfolio of operational processes fits nicely into the two solution 
delivery life cycles (portfolio and project level). 

This is not to say that EA does not need a delivery mechanism or that BPM does 
not need a planning mechanism. Rather, it proposes that such adjuncts are a 
necessary prerequisite for the effectiveness of each discipline but are not part of 
the discipline itself. As a simple example, a BPM initiative cannot identify and 
drive the need for a changed sales approach throughout an enterprise, but it can 
be an important execution mechanism for key parts of such a concept. Similarly, 
based on business strategy, an EA initiative can identify the need for the changed 
sales approach but needs solution delivery focused disciplines, such as BPM, to 
execute on those desired changes. 

Figure 3-3 reinforces the notion that the proper relationship between EA and 
BPM is not a “stack” but is rather the dynamic interaction between independent 
parallel life cycles, each with their own goals and timelines. From a planning and 
delivery convergence perspective, we must ensure that enterprise plans are 
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evolved in coordination with the delivery of solutions through change programs 
and projects. 

It is tempting to assume that such coordination always happens from the top 
down, with enterprise plans driving the definition of projects and governing their 
execution. However, in practice, plans and solutions are truly interdependent, 
and the need for coordination can be triggered in either direction. Even the best 
of plans is bound to change in the face of dynamic realities. 

To harness change, we need to separate enterprise planning concerns from 
solution delivery concerns. However, as illustrated by Figure 1-3 on page 7, we 
should not try to continuously synchronize the planning cycle with the delivery 
cycle. Rather, we should use the powers of iterative planning and iterative 
development separately and coordinate only as appropriate, as illustrated in 
Figure 3-4. 



Figure 3-4 Separating and coordinating the planning and delivery life cycles 


Because EA and BPM have different scopes and purposes, these life cycles are 
not linked in any linear or hierarchical fashion. The differences between the 
extended timeline and enterprise perspective of an EA road map and the 
execution of a specific BPM project with limited scope and deadline makes it 
undesirable to combine the two in a single life cycle. 

Consider the example of a five-year road map for a business merger, now made 
concrete in the context of BPM and EA life cycle coordination. Although the 
intended result is known, it is impractical to analyze all BPM projects in the road 
map in solution-level detail before delivering and acting on a definition of the road 
map itself (part of the EA enterprise plan). Similarly, for a business 
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transformation road map, it is impractical to deliver on the entire five-year plan in 
a single BPM delivery effort. It is much more natural to continuously define and 
adapt the scope of the next BPM project based on earlier results and overall 
progress. 

Note that this is not a matter of scope, because a BPM initiative can and often 
will have enterprise scope. It is a question of trying to achieve different goals. A 
clear separation of enterprise planning concerns and solution delivery concerns 
is important, because the two types of activities are targeted at different 
purposes and roles. 

The enterprise planning cycle results in enterprise blueprints that define a 
desired future state and are used to prioritize, select, guide, and govern the 
execution of projects. The purpose is the planning of potential changes. 
Examples of enterprise blueprints are organizational blueprints, standard 
process templates, enterprise data models, and standard network topologies. 

The solution delivery cycle results in solution constructs that are deployed in the 
business and IT operational environments. The purpose is the building of 
solutions. Examples of solution constructs are operational business processes, 
software design models, and actual network designs. 

Planning and delivery activities are typically interleaved, alternating, and iterating 
as objectives and assets evolve overtime. Note that within a business and IT 
alignment context, both the enterprise planning cycle and the solution delivery 
cycle need coverage across business and IT, including all relevant conformance 
and key performance indicator (KPI) monitoring. The level of detail and the rigor 
of governance can vary depending on environment and corporate culture, yet 
some amount of planning and some amount of delivery always occurs to ensure 
that the goals of the business are met. As far as the coordination between the 
two is concerned, at a minimum, coordination ought to occur at the beginning 
and end of each project in the enterprise. 

How can an enterprise practically enact the coordination between the enterprise 
planning and solution delivery life cycles? Do not fall into an engineering mindset 
by default. Although it is tempting to directly connect enterprise blueprint designs 
to solution constructs, typically this approach fails because enterprise planning 
and solution delivery concerns have intrinsically incomparable intentions and 
work products. For example, there is no direct translation between an 
organizational blueprint that outlines a desired future organizational structure 
and the business processes that are part of a new accounting solution. 
Understanding the relationship between the two types of models requires first 
understanding the building blocks that are used to construct each of them, such 
as standard roles, activities, and services. 
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To provide a dynamic bidirectional link between enterprise planning and solution 
delivery, we need an explicit awareness of (and distinction between) architectural 
principles, enterprise patterns, and reusable solution building blocks. Separating 
concerns into building blocks and designs facilitates effective collaboration and 
communication between the planning teams and the delivery teams in an 
organization, keeping the architecture consistent, dynamic, and alive. (For more 
details about the distinction between designs and building blocks, see 3.2, 
“Actionable architecture” on page 34.) 

For example, the standardization (as building blocks) of accounting activities and 
the organizational roles performing them can help bridge the gap between the 
enterprise design represented by the new organizational blueprint and the 
solution constructs represented by the business processes of the new 
accounting solution. 

From a life cycle perspective, in one direction we should synthesize the principles 
and patterns of the enterprise using these shared building blocks to govern 
solution delivery projects. This approach gives us better span of control in 
achieving a collective and coordinated impact throughout the project portfolio. In 
the other direction, mature solution delivery projects should synthesize their 
experiences and solution designs to produce shared building blocks to add to the 
enterprise inventory. Solution organizations should take ownership of their 
contributions to the enterprise portfolio and ensure that their projects remain 
aligned to the enterprise architecture. For additional details, see 3.2, “Actionable 
architecture” on page 34, and the IBM white paper Leveraging SOA, BPM and 
EA for Strategic Business and IT Alignment, which is available at: 
http://www.ibm.com/developerworks/websphere/bpmjournal /0812_jensen/0812 
_jensen.html 

Approaching the coordination between enterprise planning and solution delivery 
in this manner results in clear targets being set by the enterprise planning 
cycle — not as things to build for a single project, but as targets to live up to for 
any project in the enterprise, targets that can be anything from an architectural 
principle to a desired enterprise capability. 

Similarly, from the multitude of solution delivery life cycles (one for each project 
or change initiative), clear and relevant feedback to the enterprise planning life 
cycle is provided. This feedback is not in the form of enterprise blueprints to 
incorporate directly into the enterprise architecture but is feedback on project 
experiences that can range from opinions on applied targets to suggestions for 
new enterprise standards. In that manner, targets and solutions are not 
substitutes for each other, and are also not different levels of detail of the same 
underlying concept. Targets and solutions are intrinsically different things but 
must still be linked together so that their relationships can be tracked and 
governed, thereby enabling continuous improvement throughout the enterprise. 
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We provide information about the notion of linking related artifacts in 6.2, “Start 
linking” on page 85. 

It is important to realize that the BPM and EA synergies are important not only to 
IT but to the line of business as well. Without proper integration of planning and 
delivery processes throughout the enterprise, business evolution becomes 
opaque and uncoordinated. Without rigor in managing architectural change 
across business and IT, BPM solutions can quickly become brittle. Conversely, 
development of a business architecture is a principal activity that needs to be 
undertaken by EA unless appropriate artifacts can be derived from, for example, 
BPM activities. For more information, see the IBM white paper Actionable 
Business Architecture, which is available for download using FTP from: 
ftp://public.dhe.ibm.com/common/ssi/ecm/en/gbw03113usen/GBW03113USEN.PDF 

Note that improvement derived from BPM and EA has lasting value only when 
supported by appropriate collaboration and governance processes. Done in 
isolation, either discipline can trigger confusion and distrust among stakeholders 
throughout the enterprise. Done effectively, combining BPM and EA can be a key 
differentiator for successful enterprises in the drive toward continuous business 
improvement and a more agile enterprise. 


3.2 Actionable architecture 

We introduced the concept of actionable architecture as an enabler for doing the 
right things at the right time for the right reasons in Chapter 1 , “Coordinating 
planning and delivery” on page 3. Actionable architecture includes the following 
characteristics: 

► Contextual with a clearly defined purpose, motivation, priority, scope, and 
time horizon 

► Collaborative with availability to and accessibility by all stakeholders to get 
participation and commitment, often even collaboratively evolved 

► Connected with traceable links across purposes and domains, including 
appropriate levels of change and configuration management. 

► Consumable that can be understood from (different) stakeholder perspectives 
and viewpoints as required for their understanding and buy-in 

In Chapter 2, “BPM and EA defined” on page 13, we explained the value of 
architecture itself as it applies to alignment, integration, change, time to market, 
and cost reduction, noting that the value cannot be unlocked unless the 
architecture in question is indeed actionable. If for example context is lacking, 
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alignment suffers or if traceability is not maintained, integration quality and time 
to market deteriorates. 


Making architecture actionable is no small task, yet it is critical for maintaining 
coherence and consistency throughout the many moving parts that are integral 
to the combined EA and BPM space. Simply enumerating all those parts 
throughout a significant portion of the enterprise can be a daunting task and is 
certainly something that one would not want to do on a regular basis. This 
complexity points to the critically important role of the portfolio management and 
optimization life cycle. It is this cycle that keeps track of changes and ensures 
that you always have a consistent and coherent view of the current state of the 
enterprise as the foundation for both future planning and future solutions. Stated 
another way, to act on your architecture, you first need to understand its elements 
and their contextual relationships— a task for which we need a robust element 
classification scheme. 

Part of such a classification scheme has already been provided by the enterprise 
landscape defined in Figure 1-5 on page 10; however we need to classify not 
only the life cycle within which an architecture element is used, but also the 
intrinsic type of the element itself. Industry and reference models can assist in 
classifying and grouping content, but fail to call out the architectural 
characteristics that apply to such content. (For details about the role of industry 
models and standards, see Chapter 7, “The role of standards” on page 89.) 


3.2.1 Dimensions of the architectural classification scheme 

Although this book does not address architectural frameworks in general, we 
explain the following two dimensions that any architectural classification scheme 
should include: 

► Distinguishing between a building block and a design or construct 

► Distinguishing between business architecture, information systems 
architecture, and technology architecture 
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Distinguishing between a building block and a design or 
construct 

The first dimension of architectural classification that we explain is the distinction 
between a building block and a design or construct, as illustrated in Figure 3-5. 
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Figure 3-5 Classifying architectural elements as building blocks or constructs 


The collection of building blocks constitutes the reusable assets of the 
enterprise, whereas designs are constructed by composing building blocks. From 
this definition, for example, a process model is definitely a design. However, if 
you choose to promote that process model to be a reusable template or solution 
accelerator, from that perspective the process model is also a building block. 
Nevertheless, do not confuse the two concepts. Looking at a process as a 
(immutable) building block and looking at that same process as a (ever changing) 
design represents two different viewpoints and assigns different semantics to the 
process in question. 

Separating concerns into building blocks and designs can facilitate effective 
collaboration and communication between the planning teams and the delivery 
teams in an organization, keeping the architecture consistent, dynamic, and 
alive. As explained in our earlier example, the standardization (as building 
blocks) of accounting activities and the organizational roles performing them can 
help bridge the gap between the enterprise design that is represented by the new 
organizational blueprint and the solution constructs that are represented by the 
business processes of the new accounting solution. 
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Importantly from cross correlating with enterprise planning and solution delivery 
(which includes both portfolio management and optimization and projects), the 
following types of building blocks are produced by enterprise planning and 
solution delivery activities: 

► Transition targets (produced by enterprise planning activities) are templates, 
guiding principles, constraints, and architectural objectives, “things to live up 
to” and cannot be injected directly into a solution. Instead, they are used to 
guide and govern all solutions throughout the enterprise. 

► Solution accelerators (produced by solution delivery activities) are reusable 
solution building blocks that become an integral part of any solution design or 
construct that is using them. 

Not distinguishing between the types of building blocks can often lead to 
confusion and misunderstanding, for example the erroneous notion of EA 
elements and BPM elements being interchangeable just because they look the 
same, when in fact they have different semantics. EA building blocks are 
transition targets that guide and govern solutions but might never be 100% 
achievable. BPM building blocks are, from a classical software and engineering 
perspective, reusable assets from which to build BPM solutions. 

There are also two different types of design or construct: 

► Enterprise blueprints that align the designs of the enterprise with strategy and 
objectives 

► Constructs that are a part of a solution in a project or portfolio context 

As explained in 3.1, “Continuous improvement” on page 26, although it is 
tempting to directly connect enterprise blueprint designs to solution constructs, 
typically this approach fails. Understanding the relationship between the two 
types of model requires first understanding the building blocks that are used to 
construct each of them, building blocks such as standard roles, activities and 
services. Remember, it is absolutely crucial for a dynamic, bidirectional link 
between enterprise planning and solution delivery that there is an explicit 
awareness of (and distinction between) architectural principles, enterprise 
patterns, and reusable solution building blocks. Figure 3-5 on page 36 illustrates 
the dynamic relationship between different types of designs and a collection of 
shared building blocks that facilitates their construction. 

Distinguishing between business architecture, information 
systems architecture, and technology architecture 

The second dimension of architectural classification that we explain is the 
classical distinction (as witnessed by The Open Group Architecture Framework 
(TOGAF) and similar architecture frameworks) between business architecture, 
information systems architecture, and technology architecture. Business and IT 
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alignment is not restricted to providing line of business (LOB) with the 
appropriate level of IT support. Rather, it includes optimizing both business 
operations and technology platforms throughout the enterprise. 

Consequently some building blocks and constructs will be focused on the 
business only, without direct recognition of the use of IT (IT implementation 
neutral, business architecture). Some will be business-dependent IT, automating 
or digitizing parts of the business architecture (IT support for LOB, information 
systems architecture). Some will be pure technology, the IT operational 
environment of the enterprise (business independent infrastructure, technology 
architecture). 

This distinction, combined with the first classification dimension from Figure 3-5 
on page 36 (designs or building blocks), results in the well-defined framework for 
business and IT convergence illustrated in Figure 3-6. 
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Both the enterprise planning cycle and the solution delivery cycle unfold across 
all three architectural planes: 

► Business architecture includes things such as organizational blueprints (as 
planning designs), business process models (as solution designs), and 
standard roles (as building blocks). 

► Information systems architecture includes things such as enterprise data 
models (as planning designs), software design models (as solution designs), 
and software components (as building blocks). Note that information systems 
architecture encompasses data and information architecture aspects. 

► Technology architecture includes things such as standard network topologies 
(as planning models), actual network designs (as solution designs), and 
standardized router components (as building blocks). 

Most business and IT alignment initiatives explicitly or implicitly have within their 
scope assets from all three planes. By splitting into three distinct labeled 
architectures, an organization can ensure proper separation of concerns and the 
necessary focus on all three. Realization of a design or a construct can then 
occur either within a plane, driving higher level of detail, or across planes, driving 
IT support for a business blueprint or solution. 

This framework enables a clear definition of roles, responsibilities, and 
relationships across business and IT boundaries: 

► Business Executives focus on transition planning for the business 
architecture, linking business objectives to prioritization of projects. 

► Enterprise Architects focus on enterprise planning across the three planes of 
architecture, establishing and driving the necessary changes across the 
enterprise. 

► Business Architects focus on business architecture vision and blueprints, 
establishing the business context across projects in the enterprise road map. 

► IT Architects focus on aligning the information systems and technology 
architectures across the enterprise, optimizing and standardizing this part of 
the enterprise architecture 

► Solution Architects focus on solution delivery across the three planes of 
architecture, architecting deployable solutions in an efficient and effective 
manner for each project in the enterprise road map. 

► Business Analysts focus on solution delivery, creating and realizing the 
business solution design for each project in the enterprise road map. 

These roles are only examples. Similar contexts apply to other roles, all based on 
the shared architectural framework. 
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3.2.2 Applying the architectural classification scheme to EA, BPM, 
and SOA 

The architectural framework allows us to again refine your understanding of the 
synergies and interactions between EA, BPM, and SOA, as illustrated in 
Figure 3-7. 



Foundational BPM and SOA projects focus mostly on technology and information 
systems solution issues. Yet as an enterprise moves toward more advanced and 
mature understanding and objectives, the scope and impact of projects grow 
beyond the departmental level. With projects maturing through a desire to extend 
end-to-end, to transform the enterprise, and to adapt dynamically to change, 
enterprise planning becomes critical. Business architecture directs and governs 
SOA-based BPM solutions. Information systems architecture with SOA 
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governance coordinates and controls IT support for processes and services. 
Technology architecture standardizes the BPM and SOA foundation platform 
throughout the enterprise. 

In the other direction, the disciplined and systematic approach to BPM and SOA 
solution design impacts the enterprise architecture, using service-oriented 
principles and experiences in the enterprise planning activities and in 
establishing architecture principles. 

An actionable integration between enterprise planning and solution delivery 
across all planes of architecture is what ultimately drives strategic business and 
IT convergence. With the architectural synergies between EA, BPM, and SOA, 
service-orientation becomes not only the enabler of business and IT alignment 
but also the key factor that makes that alignment actionable. 

Determining which entry point to choose and discerning where the journey 
should ultimately end depends on immediate goals and challenges and on 
long-term enterprise objectives. 

For more information, see the IBM white paper Leveraging SOA, BPM and EA for 
Strategic Business and IT Alignment, which is available at: 
http://www.ibm.com/developerworks/websphere/bpmjournal /0812_jensen/0812 
_jensen.html 


3.3 Integrated strategic planning 

The concept of strategic planning is well known to any modern enterprise. 
However, strategic planning is often performed in an isolated fashion by a distinct 
group of people. In the context of optimizing the process of change, strategic 
planning cannot be done in isolation but needs to be integrated with the other 
change components of the enterprise. This section focuses on four key aspects 
of integrated strategic planning, aspects that are important to BPM and EA 
synergies. 
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3.3.1 Portfolio management 

We explained portfolio management, or rather one particular aspect of portfolio 
management, the asset aspect, when we defined the enterprise landscape in 
Figure 1-5 on page 10. However, there is more to portfolio management than the 
asset aspect. Generically, a portfolio is simply a collection of “stuff” with the 
following characteristics: 

► Somebody owns it 

► It represents a consistent subset of the system under consideration (typically 
representing a certain “tribe view” of that system) 

► It has associated with it defined value criteria (again typically representing a 
“tribe view”) 

The purpose of portfolio management is to optimize the collection of “stuff” 
according to the defined criteria. This type of management typically requires 
governance and collaboration (both of which we explain in Chapter 8, “Governing 
change” on page 99, and Chapter 9, “Effective enterprise collaboration” on 
page 109). 

The scope of interest can be different for different portfolios (such as an 
enterprise, an LOB, a department, an IT system, and other types of portfolios.) 
The type of “stuff” being considered can be different as well. For example, a CEO 
might ask if we have the right products, considering the portfolio of products 
offered by the company. A CFO might ask if we are making the right investments, 
considering the portfolio of investment opportunities. Also, an architect might ask 
if we have the correct architectural components, considering the portfolio of 
enterprise assets. 

It is quite natural for an architect or engineer to default to an asset portfolio view, 
and such a view does remain important in the context of BPM and EA synergies 
as witnessed by its prominent position in the enterprise landscape. Still, from a 
continuous business improvement perspective, other portfolio management 
considerations must be taken into account as well. 

The following types of portfolio management can be identified in most 
enterprises: 

► Product portfolio management: Managing the set of products provided by the 
enterprise typically using economically based KPIs 

► Change portfolio management: Managing the set of potential and ongoing 
changes of the enterprise typically using criteria for compliance and net 
impact or value of change 
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► Change resource portfolio management: Managing the set of resources that 
is available for changes typically using criteria for resource allocation and 
metering 

► Asset portfolio management: Managing the set of enterprise assets typically 
using criteria for consistency, configuration management, and reuse 

From an integrated enterprise planning perspective, it is critical to ensure that 
these basic types of portfolio management act in a synergistic fashion, making 
2+2=5 and not 2+2=3 (which would be the typical result of local suboptimization). 

Graphically, Figure 3-8 illustrates the desired synergies. 



Figure 3-8 Four related portfolio views on the enterprise 
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Each line in Figure 3-8 on page 43 indicates a relationship that needs to be 
synergistic. For example, change portfolio management and resource portfolio 
management need to come together for effective project (portfolio) management, 
as illustrated in Figure 3-9. 


Need 


Product Portfolio Management 



Ability 

Figure 3-9 “Project management” that governs opportunities and optimizes resource use 
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Similarly, product portfolio management and asset portfolio management need to 
come together for effective configuration management, managing the 
dependencies and relationships between business products and the assets from 
which they are built, as illustrated in Figure 3-10. 



These are just two examples of the synergistic relationships between the 
different portfolio management views. Suffice it to says that a good holistic 
understanding of these relationships is important to BPM and EA synergies in 
general and integrated enterprise planning in particular. We explain at length the 
asset portfolio management aspects in 3.1, “Continuous improvement” on 
page 26, and 3.2, “Actionable architecture” on page 34. In this section, we briefly 
consider the other three types of portfolio management. 

Change portfolio management 

Many tribes in the enterprise landscape have both the right and the obligation to 
propose desirable changes as seen from their viewpoint. This statement holds 
true for the “BPM tribe” that suggests changes based on operational 
improvement of processes and for the “EA tribe” that suggests changes based on 
the long-term architectural direction of the enterprise but also for the 
“management tribe,” the “auditor tribe,” the “public legislation tribe,” and so on. 
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The key to integrated enterprise planning is to properly register, assess, and 
prioritize all of these potential changes. Optimizing the process of change begins 
with optimizing the selection of changes to execute. 

Resource portfolio management 

The resources that are available for change are always finite and never uniform. 
Assigning proper resources and skills to the desired change initiatives is the next 
key step to optimize the process of change. Some local control needs to be 
retained, or the organization will stall in extensive bureaucracy. Having said that, 
resources must also be available to prioritize for and assign to long-term 
enterprise-wide initiatives. Finding the proper balance between optimizing the 
current state (efficiency) and re-engineering the future state (effectiveness) is 
never easy, yet remains an important part of integrated enterprise planning. 

Product portfolio management 

Finally, when changes are governed and resources properly controlled, an 
optimized change process can actively manage the portfolio of products that are 
offered by the enterprise. Organizations can adjust these products based on 
market trends and projections as well as current internal and external product 
performance. 

3.3.2 Compliance 

It has been said that “you get what you measure.” Thus, measuring compliance is 
an important part of integrated enterprise planning. In general, compliance is a 
“down stream” process that ensures conformance with higher level goals and 
policies. Compliance is needed both for investments and solutions. 

Capital planning and funding control 

Most organizations have a formal planning and control process for investments. 
As part of a funding review for any investment, a decision is made as to whether 
this investment fits the current change portfolio management plan. For small 
projects, such decisions are typically made locally either by a project manager or 
a portfolio manager. For large or cross-organizational projects, management and 
lead architects typically come together for formal scoping, sizing, and approval of 
the project. 

Note that capital planning and funding control does not stop with project initiation. 
Any major project should go through subsequent reviews as it moves through the 
various phases of the defined project life cycle. 
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Architectural compliance 

Specifically in the context of BPM and EA, downstream BPM solutions need to 
align with the enterprise architecture. BPM architects (and project teams in 
general) can seek recognition and guidance from the enterprise architects so 
that their solutions meet the guidelines and recommendations that the enterprise 
architecture provides. Compliance certification (part of compliance measurement 
processes) can be achieved using the following methods, depending on the 
criticality and complexity of the solution in question: 

► Project self certification: For self certification, solution developers and project 
teams consult the enterprise architecture building blocks and patterns for 
alignment and compliancy. In these cases, the project regularly consults with 
the enterprise architecture throughout the life cycle of development to ensure 
compliance, yet no formal review is performed. 

► Formal architectural review: For a formal architectural review, representatives 
of the EA function participate, providing a formalized external reviewer 
viewpoint. 

Regardless of the certification approach for a particular project, at any stage in 
that project’s life cycle, the project team can request an ad hoc compliance 
review by the EA team. Such informal reviews are a good source of information 
for the enterprise architects and an excellent way to demonstrate value on a daily 
basis. 

Note that, as explained previously, the enterprise architecture is not always right. 
In some cases, practical concerns must overrule architecture purity in a 
deliberated fashion. In other cases, new insight is gained in the course of a 
project that can lead to improvements in the enterprise architecture itself. Thus, 
well-defined exception handling processes must be part of integrated enterprise 
planning. 

3.3.3 Exception handling 

Exception handling is crucial in the management of risk and complexity as well 
as the tracking of emergent technologies and their success. Furthermore, good 
exception handling is a necessity to ensure that the enterprise architecture is 
flexible and valuable, not just an idealistic ivory tower. In fact, exceptions add 
experience-based insight and value that is otherwise unachievable. 

The exception handling process is usually initiated by a project manager who 
makes a request for an exception. Each exception request has its own life cycle, 
throughout which access is needed to any assets that are part of the exception 
request, including business case, architectural impacts, and project schedule. 
Good exception handling processes are usually formally defined and 
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standardized throughout the enterprise, an example of which is illustrated in 
Figure 3-11. 
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Figure 3-11 Exemplar exception handling process 


The decision making about an exception request includes the following criteria: 

► The impact (both business and technical) of not approving the exception 

► The impact on the existing infrastructure, architecture, projects, and business 

► The alternatives that have been considered 

► The cost and resource requirements for implementation of the exception 

To maintain transparency and visibility, exceptions need to be managed 
holistically throughout the enterprise, typically involving disciplines, artifact 
domains, and tools. As a consequence, exception handling might need to be 
performed outside the local “tribal” context. The trigger for such externalized 
exception handling is whether an exception is major, a perception that is 
unfortunately relative to the eyes that see. Although no definitive definition can be 
given, we provide here a selection of criteria that can aid in the assessment of an 
exception. 
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First some exemplar criteria for when an exception request is major: 

► The implementation of the exception is greater than 15% of the projects total 
budget 

► The exception introduces a new process, technology, database, location, 
organizational structure, or system that is not in the current enterprise 
architecture or that is marked as an emerging domain (for example cloud 
technology) 

► The exception relies on technology or applications that have a retirement date 
set for them 

► The exception relies on third-party or outsourced solutions 

An organization usually has an architecture review board (ARB) that reviews and 

arbitrates major exceptions. The ARB includes, but is not limited to, 

representatives from the enterprise architecture function. 

Next, some exemplar criteria for when an exception request is minor: 

► The implementation of the exception is less than 1 5% of the projects total 
budget 

► The exception does not fall into the major category 

► The exception is well bounded and understood with limited impact on other 
areas of the business 

Minor exceptions are usually approved directly by a project lead or program 

office. 


3.3.4 Benchmarking 

Benchmarking is not required for integrated enterprise planning but is a useful 
addition. There are two types of benchmarks that should be considered: 

► Internal benchmarking of organizations, systems, and solutions against an 
enterprise target 

► External benchmarking where the enterprise measures itself against an 
industry or standard benchmark 

Some benchmarks have the nature of metrics or measurements, and other 
benchmarks are architectural or organizational. Common for all benchmarks is 
that they provide a means by which progress and achievements can be 
objectively measured over time. 
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Part 2 


From tribes to 
nations 


Modern history began with independent, often warring, tribes. Each tribe had 
their own language and culture and had achieved self sufficiency through 
incorporation of all major skills in their own society. Although self sufficient, not all 
tribes had similar access to natural resources. Thus, trading emerged as an 
important part of early civilizations. With trading came the need for common 
trading languages; for instance the ancient world lingua franca of the 
Phoenicians became the basis for modern western alphabets. 

With basic trading in place, increased specialization occurred. Different cultures 
specialized in different types of high-quality goods, and classical bartering was 
replaced by trading based on established monetary systems. To avoid conflict 
among tribes, national legislation and international treaties were established. 
Libraries and the invention of the printing press allowed for rapid spread of news 
and knowledge, ultimately fueling technological innovation. All of these 
advancements lead us to today’s interconnected, digitized societies where 
collaboration towards common objectives is the norm rather than the exception. 

There are striking analogies between the historical evolution of our industrialized 
world and the challenges facing modern enterprises. Many enterprises are still 
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“tribal” in nature, in that they have not yet established common languages and 
landscapes (maps). In addition, many of the enterprise tribes do not have 
visibility to other parts of the enterprise nor, in many cases, do they care. 
Libraries are not established and processes are not defined or digitized. 
Knowledge is not analyzed to support innovation, and cross domain collaboration 
is the exception rather than the rule. We could carry on with this analogy. Suffice 
it to say that to realize better business outcomes, an enterprise needs to 
transform itself from a tribal society to a modern nation, in years not centuries. 
How do we accelerate that process? 

Part 2 focuses on how to achieve the business process management and 
Enterprise Architecture synergies in practice by transforming the enterprise 
landscape from a set of independent tribes to a collaborating and coherent inter- 
and intra-enterprise network. The primary audience for this part of the book is 
leaders and architects who need to drive transformational change with enterprise 
scope. 
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4 


BPM methods and tools 


In practice, to achieve business process management (BPM) and Enterprise 
Architecture (EA) synergy you first need a good understanding of the methods 
and tools for each discipline in isolation, including a well-defined scope for when 
such methods and tools can and cannot be applied. 

In this chapter, we use the BPM variant of IBM Software Services for WebSphere 
(ISSW) Solution Implementation Standard, referred to as ISIS, as an example of 
a core BPM method. Although this example is not an exhaustive treatment of 
BPM methods in general (with all their possible extensions), it serves the 
purpose of illustrating the key aspects of a BPM methodology. Regarding the 
BPM tooling aspects, see the example in Part 3, “A worked example” on 
page 119. 
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4.1 The scope of BPM 


As an engineering approach to process improvement, many organizations expect 
BPM to provide visibility, accountability, and control over business processes. 
The difficulty with that expectation is that, because many current business 
processes are dynamic or ad hoc, it is difficult to define a structured process 
model that represents them. In practice, the tribal language of BPM is suited only 
for processes that lend themselves to structured flow modeling. Thus, you should 
apply BPM methods and tools only to such processes. This scope includes 
processes that fall into the following categories: 

► Structured, where all process activities, rules, user roles, Ul forms, and 
metrics are defined up front 

► Structured plus dynamic, where some processes that are invoked (as 
subprocesses) from an otherwise structured process are dynamic in nature. 
The dynamicity can include both the choice of subprocess to invoke and the 
flow of the subprocess itself 

► Dynamic, where the start and end points of the process are known but the 
flow of activities is determined dynamically at run time, based on process 
state, information, policies, and so on 


Note: The scope for which BPM is well suited does not include processes 
for which an activity-centric flow cannot be defined. For example, BPM is 
not well suited for processes that can be rendered only in the form of 
business entity life cycle models. 


The core part of any BPM methodology must address all aspects of the life cycle 
of a structured business process, from analysis through design, implementation, 
deployment, execution, and finally monitoring. In addition, and in accordance 
with the BPM position in the enterprise landscape (Figure 2-2 on page 17), 
enterprise BPM methods include methodology components that address the 
portfolio management and optimization aspects of BPM, providing guidance and 
methods for identifying processes that are ripe for improvement and for improving 
the enterprise portfolio of operational processes as a whole. 
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Figure 4-1 illustrates a generalized BPM life cycle. 



Figure 4- 1 Generalized BPM life cycle 


Although the exact method steps can differ for structured and dynamic 
processes, the overall conceptual life cycle remains the same and is a core part 
of the tribal language of BPM. 


Note: The strategize stage in Figure 4-1 is not a part of enterprise planning. 
Instead, it specifically addresses measurable goals for operational process 
improvement. 


On the tooling and infrastructure side, most BPM suites appropriately support 
structured processes. However, not all BPM suites work as well for dynamic 
processes, depending on how executable artifacts can be built from process 
models, which illustrates the important point that the choice of BPM suite is not 
just about the tools. It is equally important to make sure that the BPM 
infrastructure and run times provide the desired functional and non-functional 
characteristics. 

For more information about non-functional considerations, consult the following 
resources: 

► The IBM white paper Achieving business agility with BPM and SOA together: 
Smart work in the smart enterprise, which is available for download at: 

ftp : //pub! i c . dhe . i bm.com/cornmon/ssi/ecm/en/wswl4078usen/WSW14078USEN 
.PDF 
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► The IBM white paper BPM and SOA require robust and scalable information 
systems: Smart work in the smart enterprise, which is available for download 
at: 

ftp: //pub! ic.dhe.ibm.com/common/ssi/ecm/en/wswl4104usen/WSW14104USEN 
.PDF 


4.2 The ISIS methodology 

The ISIS methodology maximizes return on investment in WebSphere products. 
In addition to technical guidance, ISIS codifies specific project management skills 
that have been acquired and defined by ISSW over the years with a goal of 
minimizing project and technical risks. 

ISIS provides product-specific best practices and artifacts based on the 
experience gathered from hundreds of consulting projects. ISIS builds on the 
Unified Method Framework (UMF) and the Unified Process (UP). UP is a 
well-defined and well-documented software development process, invented by 
Rational Software, and is the de facto industry-standard process for software 
engineering. Because of its industry-standard nature, UP is an excellent 
foundation for a method “trading language” in that the types of method artifacts 
are standardized and understandable to more than the BPM “tribe.” UP provides 
a disciplined approach to assigning tasks and responsibilities within a software 
development organization (BPM or otherwise) and is aimed at producing 
high-quality software that meets the needs of its users within a predictable 
schedule and budget. It covers the entire life cycle of a software development 
project and guides the development team through project management and 
technical activities. 

For more information about the Unified Process, see: 
http://epf.ecl ipse.org/wikis/openup/ 
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As shown in Figure 4-2, ISIS has the following phases: 

► Inception 

► Elaboration 

► Construction 

► Transition 

► Production 

The production phase is particularly important for software-related disciplines 
with a monitoring and feedback aspect (such as BPM). 



Figure 4-2 ISIS phase model 
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The ISIS phase model is an elaboration of the underlying generic UP 
architecture illustrated in Figure 4-3. 
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Figure 4-3 Unified Process architecture 


The vertical dimension, Disciplines, represents core software engineering 
activities. The horizontal dimension, Phases, represents time and shows the life 
cycle aspects of the software engineering process as it unfolds. 

The first four phases cover all parts of a project: 

► Inception: During the inception phase, project stakeholders define the scope 
of the project and its business case. At the end of this phase, all the 
stakeholders need to agree on the scope definition, cost, and schedule 
estimates. If the project fails to pass this phase, it will be canceled or changed 
significantly. 

► Elaboration: In the elaboration phase, team members analyze the project’s 
needs in detail and define its architectural foundation using the scope 
definition from the inception phase. To accomplish these objectives, members 
must have a deep understanding of the entire system. This phase is critical 
because, upon its completion, most of the system’s functionality and 
architecture must be established. 

► Construction: During the construction phase, the software is designed, built, 
and tested in iterative cycles. Developers frequently consult with management 
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and customers to get feedback. At the end of the construction phase, the 
system can be released. 

► Transition: In the transition phase of development, the software product is 
distributed to the user community. The users need to be trained to use the 
product, and new business processes often need to be rolled out. At this 
point, feedback from the users drives a new set of requirements, and the 
system’s long-term life cycle is put into place. 

The production phase occurs after the system is deployed and the project that 
delivered it is completed. This final phase addresses the ongoing support, 
operation, and monitoring. The following key activities take place in parallel 
during this phase: 

► Solution maintenance, during which potential defects are corrected. 

► Implementation of changes that correspond to the evolution of the 
requirements within the framework of the initial solution. 


4.3 ISIS for BPM 


BPM, as a business- and process-centric discipline, is not just about software. 
ISIS for BPM builds on the general ISIS base but adds extensions and 
enhancements that are specific to BPM projects (although it does not add 
portfolio management and optimization extensions, those BPM aspects are 
covered in other methods). ISIS for BPM provides best practices for developing a 
BPM solution using WebSphere BPM products and an agile development 
approach. 

The following value statements from the Agile Alliance manifesto have particular 
relevance for BPM: 

► Individuals and interactions over processes and tools 

The business process discovery, analysis, and validation activities require an 
active and efficient communication between the business (process) analyst, 
business process developer, and the subject matter experts (SMEs). Such 
activities are designed to remain as light as possible. 

► Working software over comprehensive documentation 

The suggested iterative process development approach, with its validation 
steps, is based on evidence that a working and executable process has much 
more business value than a statically documented process. All project 
stakeholders benefit from such a principle, but in particular the business users 
can rely on what they see (working process) will be run in the deployed 
solution. 
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► Customer collaboration over contract negotiation 

SMEs who define the business process, goals, and challenges are strongly 
involved in the development process. They are the customers of the final 
system, owners of the processes, and should be co-located with the 
development team during the project. 

► Responding to change over following a plan 

Business processes evolve, more often and faster than other typical pieces of 
software. This evolution is a key value of a BPM approach, enabling 
organizations to cope with the pace of change. For this fundamental reason, 
the methodology that supports process development must be tailored to a 
rapid change life cycle and must include the appropriate activities, processes, 
best practices, and work products to support such changes efficiently. 


Additional resource: For information about the Agile Manifesto, see: 
http://www.agi leal liance.org/the-al 1 iance/the-agi 1 e-manifesto/ 


Executable and working processes correspond to the activities of the 
stakeholders and the organization. Processes that are defined on paper tend to 
lack accuracy, become outdated and out of sync with the actual business 
operations, and often lack this connection. This issue does not mean that BPM 
should not adopt a model-driven approach. Instead, those process models 
should simply be executable in their own right, which is one of the value 
propositions of resource format standards such as Business Process Modeling 
Notation (BPMN) and Business Process Execution Language (BPEL). For more 
information about the role of standards, see Chapter 7, “The role of standards” 
on page 89. 

ISIS for BPM addresses the following goals of a BPM project: 

► Separate processes as manageable artifacts using well-defined discovery, 
analysis, and authoring activities. 

► Trace processes during their full life cycle from elicitation through deployment 
and maintenance. 

► Link processes to business context, challenges, and goals. 

► Develop process models using BPMN and BPEL. 

► Prepare the logical data model related to the business process modeling and 
execution. 

► Base the business process implementation on the orchestration of 
SOA-based business services. 

► Articulate the business process governance processes. 
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One of the fundamental drivers governing successful BPM projects is the 
unforgiving honesty of executable processes and software. The other 
fundamental driver is the effectiveness of people working together with goodwill, 
shared vision, and common interests (the business user, the development team, 
and other tribes involved in a BPM project). 

Roles and activities are two of the core components of a tribal language. The 
third core component— work products — play an important role in the 
establishment of appropriate collaboration across the unified enterprise. 
Consequently ISIS for BPM includes specific guidance on the following key 
project roles and the activities they are responsible for: 

► BPM analyst (Figure 4-4) 



(Figure 4-5) 
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► BPM integration developer (Figure 4-6) 



► BPM project manager (Figure 4-7) 
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Figure 4-7 BPM project manager responsibilities 


BPM solution architect (Figure 4-8) 
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► Infrastructure specialist (Figure 4-9) 
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Figure 4-9 Infrastructure Specialist responsibilities 

► Interface developer (Figure 4-1 0) 
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Figure 4-11 Monitor specialist responsibilities 
► Rule analyst (Figure 4-12) 
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Figure 4-12 Rule analyst responsibilities 
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For practical reasons, including the fact that these details are IBM proprietary, we 
do not include any additional details about the specific ISIS for BPM roles and 
activities in this book. Mapping the ISIS for BPM roles to the enterprise 
landscape defined in Figure 1-5 on page 10 might look similar to what is shown 
in Figure 4-13. 



Figure 4-13 Mapping ISIS for BPM roles to the enterprise landscape 


Note in particular how the monitor specialist has a role that extends beyond the 
boundary of a traditional project. As previously explained, the engineering, 
deployment, and operation of appropriate monitoring mechanisms is a key 
element in the feedback loop that allows continuous process improvement. 
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EA methods and tools 


Turning next to EA methods and tools, a typical Enterprise Architecture (EA) life 
cycle allows you to ensure that the organization is concentrating on the right 
things and that your architecture is aligned with the needs of the business. As 
already explained, EA does not deliver anything in and of itself; it is an enterprise 
planning discipline. Consequently, to realize the value of EA, it is important to 
focus not only on the internal tribal language of EA itself, but also on the “trading 
goods” that provide value when applied to the remainder of the enterprise. 
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5.1 Trading goods’ of the typical EA life cycle 


Figure 5-1 illustrates a typical EA life cycle. 



Project prioritization and planning is a fundamental element of the strategic 
planning component for any organization. With project prioritization and planning, 
potential initiatives are evaluated, assessed for architectural fit or risk, and 
prioritized according to long-term (enterprise) business and architecture 
objectives. 

The enterprise architecture is used as a basis for transition planning (“do the 
right things”), by creating a set of future state road maps. The future state road 
maps contain both a target state architecture and a transition plan to get to the 
future state from the current state. The project prioritization and planning function 
takes the future state road maps (one of EA’s “trading goods”) as input and goes 
through a series of trade-offs based on a correlation of market demand and 
requirements, current commitments, and the target state architectures, resulting 
in a defined set of projects (such as business process management (BPM) 
initiatives) that the organization will deliver. 

Additionally, as explained previously, EA methods provide blueprints for 
alignment with and governance of solution delivery (another one of EA’s “trading 
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goods”), so that prioritized programs and projects are executed in a consistent 
manner. Good EA methods describe and define appropriate governance 
functions and capabilities to track project architectural compliance and the effect 
of executing planned changes (“do things right”). 

Changes in projects can result in updates to the enterprise architecture or can be 
classified as valid exceptions. (See also 3.3, “Integrated strategic planning” on 
page 41 .) The EA governance function re-evaluates plans and prioritizations as 
modifications are assessed. Note that the exact embodiment of an EA 
governance function typically depends on the culture and behavior of the 
organization in which it is to be deployed. 

Based on this more detailed understanding, we can now provide a more 
elaborate version of Figure 5-1 on page 66, illustrating in particular the ongoing 
processes that are related to EA’s role within enterprise planning and within the 
enterprise at large. 



Figure 5-2 EA’s role in enterprise planning 


The colors in Figure 5-2 separate the organization’s strategy and vision activities, 
the EA life cycle components, and the solution delivery activities. Some people 
argue that strategy and vision are part of the enterprise architecture, while other 
people argue against this view. Both views can be valid depending on the 
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enterprise in question. What is “right” depends on how the enterprise planning 
life cycle processes are defined. 

Considering Figure 5-2 on page 67 in detail, the organization is constantly in a 
state of looking at the market inputs, defining its corporate vision and strategy, 
and examining its current resourcing requirements. Typical organizations ask the 
following types of questions: 

► What will differentiate our enterprise from its competitors in five years? 

► What value propositions will we offer customers to create that differentiation? 

From this assessment, the company can look at the resources that are required 
on both the business and the IT side to deliver the capabilities that are needed to 
realize the desired value propositions. For example, a superior customer 
experience might demand better Internet interactions, for which are needed new 
applications, processes, and infrastructure. These concrete needs are often 
referred to as the future state of the enterprise architecture. After the needs are 
understood, they are compared to the current state architecture (that is, the 
assets and capabilities that the organization already has) and a transition plan is 
defined that shows how the organization can progress from the current state to 
the future state. This is often referred to as upstream EA. 

With the strategy and transition plans in place, EA “execution” begins. Although 
nothing tangible is “executed” or delivered within EA itself, the EA function needs 
to guide and govern solution delivery activities throughout the enterprise. From 
an EA perspective, projects that are aligned with the transition plans are typically 
prioritized over those projects that do not align. This determines the projects that 
the EA function would like to have funded and initiated (or continued) within 
solution delivery. 

As solutions are developed, EA assets such as models, building blocks, rules, 
patterns, constraints, and guidelines are used for guidance and governance 
(often referred to as downstream EA). Where the standard EA assets are not 
suitable for a project, exceptions are requested from the governance board. 
These exceptions are tracked carefully. Where EA assets are frequently the 
subject of exception requests, they must be examined to see if they really are 
suitable for the organization. If we are not doing things the way we said we 
wanted them done, then we must ask if our target architectures are optimal as is 
or whether they should be adjusted. This helps keep the enterprise architecture 
current and useful. 

Periodic updates to the organization’s vision and strategy require a periodic 
re-assessment of the enterprise architecture future state. This re-assessment 
typically results in another look at how the organization can differentiate itself in 
five years, what value propositions it can offer, the capabilities and resources 
needed, and so on. Then, the transition plan is examined to see if it is moving the 


Combining BPM and EA for Better Business Outcomes 



enterprise in the right direction, if it is not, the transition plan is updated. This 
illustrates the continuous, independently, cyclic nature of EA. 

The remainder of this chapter defines typical EA method and tooling capabilities 
and addresses in some detail EA maturity and value propositions. Note that most 
enterprises need to start small and only grow scope and ambitions as their 
architectural maturity increases. 


5.2 EA capabilities 

Although the EA method, tool, and middleware capabilities that we describe in 
this section are not exhaustive, they are nevertheless fundamental in that any 
mature EA function will apply them in one form or another. Thus, they are all part 
of the core “tribal language” of EA. 

5.2.1 Supported domains of change 

In the context of EA, we briefly explain potential domains of change in 2.3, 
“Enterprise Architecture” on page 18. In practice, a particular EA framework uses 
its own taxonomy for the domains of change that it supports, which in turn affects 
the terminology and metamodel of the framework. 
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As an example, The Open Group Architecture Framework (TOGAF) 9 defines the 
domains of change illustrated in Figure 5-3. 



Figure 5-3 TOGAF 9 change domains 

Notice how the four main domains are directly mappable to the generic 
architectural framework for business and IT convergence defined in Figure 3-6 
on page 38. The business architecture maps to the business domain, the 
technology architecture maps to the technology domain, and the data and 
application architectures combined map to the information systems domain. This 
mapping illustrates that although a particular EA framework has its own domain 
structure, any general-purpose EA framework will always be mappable to the 
fundamental domains of business, information systems, and technology. 


5.2.2 EA artifacts 

This section addresses the types of artifacts that are an integral part of the 
definition of an enterprise architecture. Artifacts are goods that are produced by 
the EA tribe. They are required components for the enterprise architecture to be 
represented and documented in a standardized manner. 

Model 

An EA model is the definitive representation of the target system, thereby also 
defining the bounds of the EA working environment. The EA model must contain 
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all the core model elements and their relationships and is, in general terms, not 
directly visible as a whole. Some EA models might contain alternative or 
additional model elements or relationships. Note that models do not include 
visual representation information. 

Metamodel 

A metamodel defines the types of elements that are allowed in the EA model, 
together with their permitted relationships. The element types are typically 
categorized according to the domain structure in the applied EA framework, as 
shown in Figure 5-4. 



Figure 5-4 Part of the core metamodel for TOGAF 


Views and viewpoints 

A view is a rendering of part of the EA model that displays a selected set of 
model elements and their relationships. Views can be visualized as tables, 
matrixes, textual stanza, relationship diagrams, or other types of visual elements 
to satisfy the consumability needs of a particular stakeholder. A view is different 
from the EA model in that it is a visual representation of some select set of model 
elements. 



Figure 5-5 A view of the EA model showing the Credit Verification business service 


An EA model can be visualized in various manners, using different views on that 
same model. To standardize stakeholder views, many EA frameworks include 
predefined viewpoints. A viewpoint is a description of information that is found in 
a view. Optionally, a viewpoint includes a declaration of the view’s notation (table 
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structure, matrix format, diagram symbols, and layout) and model manipulation 
rules for that view. Generally, predefined viewpoints are associated with a 
modeling role. Table 5-1 shows sample viewpoints that are defined in TOGAF 9 
and the domain within which each viewpoint is typically used. 

Table 5- 1 TOGAF 9 viewpoints and domains 


Viewpoint 

Domain 

Principles Catalog 

General 

Stakeholder Map 

Architecture vision 

Value Chain Diagram 

Stakeholder Position Matrix 

Stakeholder Management Approach Dashboard 

Stakeholder Category Diagram 

Solution Concept Diagram 

Strategy Map 

Enterprise Direction Diagram 

Organization/Actor Catalog 

Business architecture 

Role Catalog 

Business Service/Function Catalog 

Business Interaction Matrix 

Actor/Role Matrix 

Business Footprint Diagram 

Business Service/Information Diagram 

Functional Decomposition Diagram 

Product Lifecycle Diagram 

Organizational Decomposition Diagram 

Business Process Diagram 
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Viewpoint 

Domain 

Data Entity/Data Component Catalog 

Information systems 
(data architecture) 

Data Entity/Business Function Matrix 

System/Data Matrix 

Class Diagram 

Data Dissemination Diagram 

Entity Relation Diagram 

Application Portfolio Catalog 

Information systems 

Interface Catalog 


System/Organization Matrix 

Role/System Matrix 

System/Function Matrix 

Application Interaction Matrix 

Application Communication Diagram 

System Architecture Diagram 

Application and User Location Diagram 

System Use-Case Diagram 

Technology Standards Catalog 

Technology Architecture 

Technology Portfolio Catalog 

Network Concept Diagram 

System/Technology Matrix 

Environments and Locations Diagram 

Platform Decomposition Diagram 

Project Context Diagram 

Opportunities and Solutions 

Benefits Diagram 

Requirements Catalog 

Requirements Management 
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5.2.3 EA repository and automated harvesting of EA artifacts 

The task of maintaining an enterprise architecture model is often seen as 
expensive, involving lots of hard work. The more you can automate and reduce 
the cost of maintaining the enterprise architecture, the easier it can be to adopt 
and use. Organizations applying EA require a capability to create or update their 
architecture from existing sources. 

Fundamental to automating the maintenance of the EA model is to have a 
repository for storing and managing its model elements. A well-structured 
repository also supports the ability to distribute architecture content globally to 
different teams and the ability to access the EA model at different levels of detail. 

With an EA repository in place, the operational part of the EA model can be 
populated directly from a number of sources that are associated with specific 
architecture domains, such as the following examples: 

► Lightweight Directory Access Protocol (LDAP) directories for organizational 
information 

► Process servers for process models 

► Change and configuration management databases for application and 
technology components and configurations 

Similar sources exist for development-related artifacts in the form of development 
repositories and registries. Note that appropriately leveraging the synergies 
between BPM and EA also has an effect on harvesting solution delivery artifacts 
and experiences for use in the enterprise architecture. 
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5.2.4 Impact analysis and analytics 


Understanding the impact of change is a key benefit of EA. Thus, the impact 
analysis for a model change is important. As illustrated in Figure 5-6, you must 
be able to view traceability across selected subsets of the EA model and to 
create views that represent the specific impact questions that are asked. 



For more advanced queries, analytics capabilities are required for in-depth 
processing of the EA model. The enterprise architect uses analytics to combine 
various impacts, conformance levels, and states of the architecture for any 
particular view. Adding analytics information to views of the EA model is also 
effective in demonstrating the value of an EA model to different stakeholders. 


5.2.5 Simulation 

A simulation is a type of analysis that allows the enterprise architect to test and 
predict the outcome of information or events that are triggered in the model. The 
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benefit of simulation is that it allows prediction of bottle necks in the EA model, 
allows looking at best use of resources, and allows simulating costs and risks 
that are associated with change proposals. 


5.2.6 Current versus future state analysis 

When choosing a future state option, there are a number of capabilities that can 
assist decision making and transition planning. In particular, road maps and 
comparison tools are key capabilities in the armory of an enterprise architect: 

► Road maps: Road maps are a temporal view that is applied to an underlying 
EA model whose elements often can have specific temporal properties. 
Specifically, road maps make visible the evolution of the EA model over time, 
which is important in current and future state analysis because it provides a 
view of the EA landscape at a designated future point in time. 

► Comparison tools: Automating the comparison of a current state versus a 
future state or of a future state A versus a future state B allows the enterprise 
architect to efficiently perform key comparisons of, for example, gaps between 
two states or semantic changes between two EA model representations. 
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5.2.7 Transition planning 


Comparison tools provide gap analysis capabilities, but a transition plan defines 
the steps that are needed to move from the current state to the future state. A 
transition plan shows the sequence and the resources that are required over time 
to get to that desired future state as illustrated in Figure 5-7. 



The transition plan forms part of the target architecture cost and value 
assessment. It is important not to compare just the current state versus the target 
state architecture in a purely architectural fashion but also to take into account 
the steps and costs that are associated with getting there. 
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A transition plan is often “executed” by the creation of successive candidate 
projects to perform the steps of the transition. Such projects are prioritized with 
the remainder of the project portfolio. (For information about integrated strategic 
planning, see 3.3, “Integrated strategic planning” on page 41 .) Note that there 
can be multiple options in a transition plan about how to move from a current 
state to a target state; these options can be evaluated against each other. 


5.3 EA maturity 

Organizations operate at various levels of maturity. Initially, many EA initiatives 
start off with an enterprise inventory view of their environment. They look at the 
portfolio of EA assets (or a subset thereof) and make assessments about 
capabilities that are supported versus capabilities needed, often making tactical 
decisions to retire components in their portfolio based on current usage and cost 
as illustrated by the left side of Figure 5-8. 



Figure 5-8 EA adoption 

As organizations mature, standardization becomes important. The ability to have 
a common technology framework and application infrastructure as well as best 
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practices and guidelines for the delivery of software and solutions becomes 
essential. At this stage, enterprises seek to add value by evolving IT 
environments in a repeatable and scalable fashion. In the analogy of “from tribes 
to nations,” this evolution corresponds to the beginning stages of a trading culture 
where bartering is increasingly based on standardized monetary measures. 

Moving beyond the standardization stage, enterprises are looking to ensure that 
IT infrastructure and solutions are directly representative of business needs and 
requirements. Enterprise-wide business process blueprints need to be 
understood to ensure that the information systems environment appropriately 
supports the end-to-end business. Furthermore, to avoid complexity and cost, 
enterprises at this stage need to ensure that IT is not built in operating unit silos 
but is evolved based on consolidated enterprise needs. The tribes of the 
enterprise begin to work together towards common goals. 

Ultimately, those organizations that use EA to support the realization of strategy 
can effectively manage in-bound demand and requirements, can assess risk and 
technology alignment, and can produce different architectural options in support 
of quick and prudent decisions. 


5.4 The value proposition for EA 

Justifying the cost of EA is a common issue. Cost justification is the most difficult 
communication task facing many enterprise architects because of the following 
common misperceptions about EA: 

► It takes too long (not understanding that enterprise planning is a continuous 
life cycle of its own) 

► It costs too much (erroneously treating EA as a cost center rather than a 
business and IT enabler) 

► It is an ivory tower that has no real relevance to the things that we do in the 
real world (not appreciating and properly using the synergies between EA and 
solution delivery disciplines such as BPM) 

Requests for cost justification are historically based in an age where cost savings 
were associated to the fact that computers could replace people’s jobs and that 
automating repetitive tasks led to an improvement in quality and time. 

The market has changed significantly. Computers are no longer differentiating 
assets in their own right; they are commoditized and well understood by most 
organizations. The differentiation lies in how they are used for business 
enablement. Doing things quicker, cheaper, and faster with computer technology 
alone no longer provides competitive advantage. In addition, cost justification in 
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terms of replacing resources is no longer the only driving value proposition for IT 
investment. 

In contrast to computers, a well-defined architecture is in fact an asset and 
should be treated as such. Organizations invest in assets to drive value and to 
accomplish tasks that were not possible before. If something is used once, it is 
an expense; however, if it is used repeatedly, it becomes an asset. In this sense, 
a good architecture should be considered an investment and an asset that is 
maintained continuously and used repeatedly. 

Thus, although EA will never realize a return on investment in and of itself (after 
all EA does not deliver anything tangible), the proper use of EA assets can 
generate significant value above and beyond what solution delivery activities in 
isolation can. This concept is consistent with analysts and industry leaders 
having stated several years ago that a return can be realized on EA but not from 
the EA program itself. 

Figure 5-9 represents core value propositions for EA in general. These are goals 
towards which EA assets can be applied to generate real enterprise value. 



EA can provide value in the forms of the following concepts: 

► Alignment 

Do the systems in the organization meet the change in the market conditions 
and our strategy? Is the functionality and quality of systems directly 
attributable to the requirements that drive them? Market demand and EA need 
to be aligned and correlated to respond to market movements and challenges. 

► Integration 

Information must be available to the right stakeholders in the organization in 
the right format at the right time to make appropriate decisions about potential 
plans. EA can look holistically at business solutions and IT assets and can 
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support “plug and play” of applications and technology infrastructure to 
provide for new initiatives as the enterprise evolves. 

► Manage planned change 

The architecture description or blueprint provides the basis for managing 
change over time. After all, we would not attempt to modify our own house 
without first seeing the building plans, electrical wiring diagram, and how 
these parts fits into the remainder of the environment, such as water services, 
gas, and so on. 

There are three basic options for considering and managing change: 

- Let the architecture go obsolete, remove it, and build it again. This 
approach is slow and does not enable innovation. 

- Change the architecture, and determine what happens through trial and 
error. This approach is a high risk, because serious issues can occur 
before errors are detected. 

- Continuously maintain the EA model, and process changes in a structured 
fashion as they occur. This is usually the most effective way to approach 
EA and certainly the method that best enables the synergies between 
BPM and EA. 

► Time to market 

This incentive is an important part of the value proposition for EA, although 
often overlooked. 

There are many examples of organizations that excel in reducing time to 
market and use that ability to great effect. These enterprises might not have 
the best technology, but they are the thought leaders in their field and quick 
time to market is part of their business strategy. To achieve time to market, the 
business and IT architecture must be well understood and the effects of 
change must be easily identifiable with a high degree of certainty, thus 
reducing risk when executing rapid change. Furthermore, reuse of architecture 
building blocks is important in guiding agile enterprises effectively. 

► Drive out costs 

This particular value proposition is often the place organizations begin their 
EA journey (as illustrated in Figure 5-8 on page 78). Consider as an example 
the application architecture domain. We can rationalize the application 
portfolio by analyzing it to ensure that it meets the following criteria, which are 
natural aspects of EA analysis: 

- Supports the required business and IT capabilities 

- Supports no more than those required business and IT capabilities 

- Supports the organization with the most optimal solution in terms of cost 

- Selects the applications that have the best architectural fit 


Chapter 5. EA methods and tools 81 



82 Combining BPM and EA for Better Business Outcomes 



6 


Stop copying; start linking 


Now that we have presented business process management (BPM) and 
Enterprise Architecture (EA) in isolation, we explain in this chapter how to link 
and synergistically integrate the two. 

In Part 1 , “Better business outcomes” on page 1 , we explain the need to 
collaborate and coordinate, not synchronize, across EA and BPM boundaries. 
You do not want to change all ongoing projects every time long-term plans are 
adjusted and you do not want to scrap enterprise plans and standards just 
because a project cannot completely meet the targets that have been set. The 
challenge is how to achieve such coordination in practice without breaking the 
principles of actionable architecture. 
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6.1 Stop copying 


Visibility and traceability are key parameters for any successful integration of EA 
and BPM, especially because such environments typically involve the use of 
multiple modeling tools in support of the different roles and model types. One 
way of creating visibility and traceability is by having all modeling tools use a 
single global repository. However, in many cases, this approach is simply not 
practical either due to the tools involved or the infrastructure mix or because 
different roles need different user experiences, leading ultimately to different 
model management requirements. 

When collaborating across modeling domains and tribal boundaries, the typical 
approach has historically been to exchange artifacts by copying, in many cases 
even using transformations when doing so. Such a copying approach introduces 
several issues: 

► Point-to-point proprietary integration 

► Loss of information through transformation or conceptual mismatch 

► No visibility across domain boundaries 

► Change management becomes complicated or impossible because it is not 
clear who owns the authoritative truth 

► No support for artifact life cycle management 

Emerging industry standards, such as Business Process Modeling Notation 
(BPMN) 2.0 and Service-oriented architecture Modeling Language (SoaML), 
incorporate quasi-normative guidelines that reduce the need for transformations 
and proprietary integration, yet standard formats are no help for the 
manageability issues. The only way to address these issues is to stop copying 
artifacts. 

The root of the problem is that when copying an artifact using export and 
subsequent import, you then have two physically distinct and unconnected 
copies of the same artifact. In fact, the copying approach breaks at least three of 
the actionable architecture principles. Context is lost on the other side of a copy, 
an “over the fence” exchange is not collaborative, and the traceable origin of an 
artifact is lost on the copy. 

Copying artifacts fundamentally creates potentially massive amounts of rework 
and institutionalizes the need for constant synchronization across environments 
and tools. Even worse, a copying approach blurs the lines of ownership and does 
not respect the different life cycles of various types of model artifacts throughout 
the enterprise landscape. If you want to use the trading goods that are produced 
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by another tribe, you do not need to take over complete responsibility and 
ownership for those goods. 

Note that copying is subtly, but importantly, different from cloning an artifact to a 
related but distinct artifact. The following examples should help clarify the 
distinction: 

► Copying involves exchanging a service model between a service modeling 
tool and a process modeling tool to use that service model for process 
orchestration. 

► Cloning involves taking an EA process template and cloning it (as a starting 
point) to a different process model that is part of a particular solution. 

With copying, if you changed the service model in any of the tools, you would 
need to synchronize that change to the other tool because both copies are in fact 
one and the same artifact. With cloning, even though the clone is initially 
bit-by-bit the same as the original (or possibly a transformation of it), the clone 
has its own distinct identity and life cycle independent of the original. Although 
derived from the original trading goods, the clone is a completely different work 
product with its own independent semantics. 

After all, even though you modify a (cloned) process model for a particular 
solution, in most cases that does not mean that you want to change your 
enterprise standard. Having said that, in support of visibility, traceability, and 
future collaboration, it is still important to maintain a link from a clone to its 
original source. Although this is just an example, it illustrates that when crossing 
domain boundaries, there is no good reason to do exchange by copy. Either a 
simple link that provides visibility and traceability is enough, or a clone that has 
its own unique identity and that is linked back to the original is needed. 


6.2 Start linking 

The challenge of creating large-scale visibility and traceability was faced in the 
early days of the Internet and interestingly the World Wide Web pioneers chose a 
radically new approach compared to the historical use of shared or federated 
repositories. The web today is based on the notion of linking different sorts of 
pages through light weight, standardized HTTP references and on accepting the 
fact that such references might be broken from time to time. Broken links are 
simply the price paid for avoiding the expense of copying or the rigidity of a global 
repository. 
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In the EA and BPM integration space, whether a given situation can be handled 
by simple links or whether it requires cloning, a similarly standardized, 
tool-neutral way of linking artifacts across modeling domains is needed. Such 
links must have the following characteristics: 

► Transparency 

► Bidirectional visibility 

► Version sensitivity 

► Robustness against change 

These characteristics are the standardized linking semantics that are being 
addressed by the Open Services for Lifecycle Collaboration (OSLO) industry 
initiative. For more information, see: 
http://open-services.net/html /Home.html 

Figure 6-1 illustrates this style of linking that will form the basis for future 
generations of tools and tool integrations. 



Figure 6-1 Internet-style resource linking 


Linking provides for a more seamless experience than copying and offers better 
visibility and traceability across role and tool boundaries. Process models can be 
linked directly to the service models that they orchestrate, with the dependencies 
visible to both the business analyst and the service architect. Services can be 
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linked to the information artifacts on which they depend and can be visible to both 
the service architect and the data architect. EA transition targets can be linked to 
the solution models that they guide and govern, with the relationships visible to 
the enterprise architect and to anyone working on the solution model in question. 
In short, we need to start using transparent links between artifacts wherever we 
can and tools need to essentially become viewpoints onto a linked resource web. 

Even in the case where a cloned copy is truly needed, such as when seeding a 
new BPM solution with an EA template, clone the original artifact in a traceable 
and linked fashion and do not exchange the artifact by copy. This approach 
provides an experience that has the following characteristics: 

► People-centric, supporting collaboration across participants yet respecting 
domains of authority 

► Transparent, providing cross domain visibility through many-to-many artifact 
relationships 

► Managed, with tool assisted management of artifact links 

► Coordinated, with lightweight coordination that focuses on synergies instead 
of attempting heavyweight complete synchronization 

In contrast to copying, a linking approach does support the principles of 
actionable architecture and is the appropriate choice for integrating EA and BPM 
in a synergistic fashion, as illustrated in Figure 6-2. 



Figure 6-2 Unleash BPM and EA synergies using flexible linking 
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For more details (with visualizations) about how to do basic linking between BPM 
and EA artifacts in practice, see Part 3, “A worked example” on page 1 19. At this 
point simply note that linked EA artifacts are not limited to process blueprints. 
Many different types of EA artifacts can guide and govern the same BPM solution 
process model. 

Technologies to support a linking approach are rapidly evolving. Already many 
asset management repositories support any-to-any relationships between assets 
in the repository and provide basic elements of social collaboration. Moving 
forward, such relationships need to be standardized and federated as 
semantically consistent links between repositories with the kinds of properties 
that are addressed by the Open Services for Lifecycle Collaboration initiative. 
Indeed, an amalgamation of basic linking with traditional elements of advanced 
search, model-driven development source control, and project management and 
tracking is a core element of the work ahead and a key component of any 
enterprise trading language that supports the transition from tribes to nations. 
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7 


The role of standards 


We have already mentioned standards, such as Business Process Modeling 
Notation (BPMN), Open Service for Lifecycle Collaboration (OSLO), and 
Service-oriented architecture Modeling Language (SoaML), in previous parts of 
the book. Standards are an important part of establishing a common trading 
language for the modern enterprise, internally and externally. The following types 
of standards are important in the context of this book: 

► Semantic standards, such as the The Open Group SOA Ontology, define 
common concepts and terms in support of effective communication and 
understanding. 

► Format standards, such as BPMN 2.0, SoaML, Service Component 
Architecture (SCA), Reusable Asset Specification (RAS) and OSLO, support 
collaboration and consumability. 

► Framework standards, such as The Open Group Architecture Framework 
(TOGAF), provide context and structure. 

► Industry model standards, such as the open standard TM Forum Business 
Process Framework (eTOM) and the IBM proprietary Banking Information 
Framework (IFW), act as reference models, benchmarks, and accelerators for 
content and executables. 

► Process improvement standards, such as Capability Maturity Model 
Integration (CMMI) and Information Technology Infrastructure Library (ITIL®), 
act as benchmarks and accelerators for architecture, engineering, and 
management processes. 
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In reality, few enterprises need to consider all these different kinds of standards, 
at least not for the first few years of a transformation journey from “tribes” to 
“nations.” Having said that, however, it is important to understand the value of 
each type of standard to better discern which standards to use and when to use 
them. In particular, understanding the different format standards is critically 
important for the immature transformation initiative. Without such understanding, 
it is easy to produce assets that are not robust against change or that fail to be 
understood by anyone outside the initial team. 

To exemplify the different categories of standards and why each has value in the 
context of business process management (BPM) and enterprise architecture 
(EA), we address the following standards that are of particular interest to this 
book: 

► Semantic standards: The Open Group SOA Ontology Technical Standard 

► Resource format standards: BPM N 

► Linking format standards: OSLO 

► Framework standards: TOGAF 

► Industry model standards: IFW 

► Process improvement standards: CMMI 


7.1 Semantic standards: The Open Group SOA 
Ontology Technical Standard 

The Open Group Service-Oriented Architecture Ontology Technical Standard is 
intended to develop and foster a common understanding between business and 
IT communities regarding service-oriented architecture (SOA) concepts and 
terminology. The ontology defines the concepts, terms, and semantics of SOA in 
a common language that allows for more precise and straightforward 
communications throughout the enterprise, reducing ambiguity and 
misunderstandings. 

For more information about The Open Group SOA Ontology Technical Standard, 
see: 


https://www2.opengroup.org/ogsys/jsp/publ ications/Publ i cat ionDetai Is. js 
p?catalogno=cl04 

Semantic standards, such as the SOA Ontology, provide common terminology 
and concept mapping that business and technical people can employ to discuss 
problems and opportunities. Furthermore, such semantic standards bridge 
different architecture, engineering, business, and marketing domains. Although 
rarely complete from a coverage perspective, semantic standards create a 
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consistent foundation for inter- and intra-domain communication, a foundation 
that becomes the backbone of the lingua franca for the enterprise landscape. 

Despite years of evolution in systems, people who work with SOA, BPM, and EA 
are often still divided by differing uses of common terms. Definitions of routinely 
used words (such as process, service, component, system, and task) and how 
these terms relate to each other, can have varied meanings depending on who or 
what product or tool is doing the defining. In particular, business and technology 
people might not assign the same definitions or understanding to a concept. 

As we have already argued, making sure that you are “speaking the same 
language” is essential for any architect to be able to communicate effectively with 
IT, business, and marketing professionals within the enterprise and with vendors 
and suppliers outside the enterprise. Until recently, the industry has had little 
focus on semantic standards. Most standardization efforts have addressed 
resource format standards. That balance needs to change, especially because 
format standards have little value without common semantics for the kinds of 
things that the format standards apply to. After all, what good is a standard for 
process model notation if we do not agree on the concept of process itself? 


7.2 Resource format standards: BPMN 

BPMN 2.0 seems to be the next big thing in BPM, but should we really care from 
a business perspective? BPM is a business-oriented discipline after all, so does it 
really matter what the IT industry does to make processes executable? How 
does BPMN 2.0, with its focus on standardized exchange of processes, fit with 
the notion that we should really stop copying and start linking instead across 
disciplines and domains such as BPM and EA? And what has any of that got to 
do with agile change? 

Table 7-1 provides some basic information about the BPMN 2.0 standard. 


Table 7- 1 What the BPMN 2. 0 standard is and is not 


BPMN 2.0 is... 

BPMN is not 

► A formal industry standard 

► A standardized way of expressing 
processes (common visual language) 

► Applicable (with value) to a pure 
business domain 

► A foundation for standardized 
exchange of process resources 

► Executable at the highest level of 
detail 

► A substitute for SOA standards 

► A process editor (but it can support 
one) 

► A programming model 

► A platform 

► A discipline 

► An architectural approach 
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From this list, we can determine that there are two unique value propositions for 
BPMN 2.0 Only one of these is related to standardized exchange; the other value 
proposition is related to the need for a common, standardized language that 
allows us to talk about and define business processes. Such a common, 
standardized language is critically important for a tribal enterprise desiring to 
become a nation, and is not related to “copying” at all. 

In short, BPMN 2.0 remains integral to the future of both BPM and EA, but we 
should adopt a perspective on how best to apply BPMN 2.0 that is more nuanced 
than much of what has so far been discussed publicly. A perspective that must 
include how to use BPMN 2.0 for consumability within and across both BPM and 
EA, as well as how to merge linking and BPMN 2.0 resource representations in 
an effective fashion. 


7.3 Linking format standards: OSLC 

Open Services for Lifecycle Collaboration is an open community of individuals 
from customers, business partners, systems integrators, competitors, open 
source communities, and academia, as shown in Figure 7-1 on page 93. The 
community focuses on interoperability interfaces between life cycle tools for 
software and systems development, using a technology-neutral approach that is 
based on Internet standards and protocols. 
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Home About Community 


Open Services for Lifecycle Collaboration 

open community, open interfaces, open possibilities. 


Open Services for Lifecycle Collaboration (also known as OSLO or Open Services) 
is a community effort to help software delivery teams by making it easier to use 
lifecycle tools in combination. The OSLO community is creating open, public 
descriptions of resources and interfaces for sharing the things that software delivery 
teams rely on, like change requests, test cases, defects, requirements and user 
stories. 

By agreeing on common specifications for lifecycle resources and the services to 
access them, we can eliminate traditional barriers between tools and open the door 
to new forms of collaboration. OSLO can bring value to software delivery teams and 
tool providers alike, from fhe most Agile to the most ceremonial of projects, and for 
commercially-licensed, open source, and internally developed tools. More. 


With OSLC's open and 
scenario-based approach, 
businesses benefit from the 
ability to tie disparate tools 
together. This collaborative 
approach gives our 
consultants the flexibility to 
make lifecycle tool choices 
based on specific client 
project demands. 

Randy Vogel, Accenture 


Learn more 

. Presentation: ALM Integration in a 
Web 2.0 World 

. Presentation: RESTfui Work Items: 
Opening up Collaborative ALM 

. Podcast: Open Services bears first 
fruit. A conversation wth Steve 
Abrams, Mik Kersten, and Carl 
Zetie. 

. Whitepaper: The Case for Open 
Services 

. Podcast: John Wiegard and Steve 
Abrams introduce the OSLC 
initiative 


News and events 

• Implementations delivered for 
Change management 1 .0 spec 
(press release) 

. Change management 2.0 spec 
workgroup expanding 
participants. 

. Requirements management and 
Asset management workgroups 
draft early specs. 

> Primer authored for Software 
Estimation and Measurement 

> New Reporting workgroup call for 
participation. 


Quick links 

. Wiki: Open Services 
specifications 

. Mai ing list: OSLC community 
. Blog: Let’s try something 
different- Carl Zetie's 
commentary on OSLC 
. Twiier- follow us: @oslcNews 


Figure 7- 1 Front page of open-services.net 


What is important in the context of this book is that contrary to many other format 
standards, the OSLC specifications do not focus on the format of a resource but 
on standardized semantics and formats for links between resources. OSLC 
specifications importantly include both Representational State Transfer (REST) 
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interfaces that must be supported for creating, managing, and linking resources 
and user interface components that must be provided for remote lookup, search, 
and so on. Different OSLC servers own and control each their own OSLC 
resources but provide just enough standardized interaction semantics to support 
an integrated network of linked resources. This environment is not a federated 
repository or a set of isolated repository islands but is a semantic resource web 
that is similar in nature to the World Wide Web of Internet pages. 

Without an industry standard for links, it would be hard, if not impossible, to stop 
copying and start linking throughout the enterprise landscape. Consequently, the 
OSLC specifications are a critical enabler for the transition from tribes to nations, 

For more information about OSLC, see: 
http://open-services.net/html /Home.html 


7.4 Framework standards: TOGAF 

The Open Group Architecture Framework is a documented set of techniques and 
tools for developing and supporting EA. TOGAF describes a metamodel the 
views and viewpoints that are associated with the metamodel, and the types of 
phases that a typical EA practice performs. The phases of TOGAF are known as 

the Architecture Development Method (ADM), as illustrated in Figure 7-2 on 
page 95. 
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Each phase consumes and produces artifacts that assist in the development of 
the architecture. Underlying the phase model is an extensible abstract artifact 
metamodel that can be interpreted and augmented for a particular enterprise, 
serving as both a benchmark and an accelerator for architecture development. 
Table 7-2 lists some of the typical extensions to the TOGAF core metamodel. 


Table 7-2 TOGAF 9 extensions 


Metamodel Portion 

Description 

Core 

Core metamodel concepts for TOGAF 9 

Governance 

Extension to support in-depth operational governance 

Services 

Extension to support definition of discrete business and application 
services 

Process Modeling 

Extension to support process modeling 
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Metamodel Portion 

Description 

Data Modeling 

Extension to support data modeling 

Infrastructure Consolidation 

Extension to support consolidation of applications and technology across 
locations 

Motivation 

Extension to support linkage of drivers, goals, and objectives to 
organizations and services 


In general, framework standards such as TOGAF provide a much needed 
classification and structure for work products, which is especially important for 
cross-domain collaboration where crisp context and linking are required. 

TOGAF 9 is particularly relevant to this book because we refer to TOGAF 9 work 
products in the EA-specific parts of the book. Furthermore TOGAF 9 supports a 
governance process that is completely synergistic with the overall approach to 
governance for change that we have proposed. TOGAF is only one of the 
commonly available EA frameworks. Other frameworks, such as the IBM 
Enterprise Architecture Method, provide similar content and work products and 
one framework can be mapped onto the other. 

For more information about TOGAF, see: 
http://www.opengroup.org/togaf/ 


7.5 Industry model standards: IFW 

The IBM Banking Information Framework (IFW) is a typical example of an 
industry asset that is a benchmark, a reference model, and an accelerator all at 
the same time. These aspects have differing importance to the distinct life cycles 
of the enterprise landscape as follows: 

► As a benchmark, IFW provides input to and guidance for enterprise planning 
blueprints and standards. 

► As a reference model, IFW provides structure and classification to the 
resources and asset in the portfolio management and optimization life cycle. 

► As an accelerator, IFW provides seed content for projects and solutions. 

Not all industry model standards will on their own address all three of these life 
cycle concepts, but all three are typically needed for an accelerated and 
sustainable transformation from tribes to nations. Consequently, an enterprise 
embarking on such a transition should consider up front which industry models 
and industry model standards to apply and use those industry models and 
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standards right from the beginning of the journey. After all, creating models and 
content is relatively easy compared to the challenges that are intrinsic in 
managing and governing what has been created over time. 

For more information about IFW, see: 

http : //publ ib.boulder.ibm.com/infocenter/dmndhel p/v7r0mx/i ndex. jsp?topi 
c=/com. i bm.ws . i cp. bkkpayfepl . doc/bkk/pay/paymdev/concept/ci /i ndstds/c_i 
fw.html 


7.6 Process improvement standards: CMMI 

Capability Maturity Model Integration (CMMI) is a process improvement 
approach that helps organizations improve performance. CMMI can be used to 
guide process improvement for a project, a division, or an entire organization. 
This type of improvement is not process improvement in the BPM sense of 
optimizing business processes. Instead, it is improvement of the requirements, 
engineering, and management processes on which an organization needs to 
focus for effective development and collaboration. 

Although not directly applicable to the enterprise landscape, CMMI does provide 
a catalogue of engineering processes for which we need a common language 
and appropriate collaboration patterns. Furthermore, CMMI allows you to 
benchmark the maturity of existing engineering processes and to measure 
progress over time. 

In general, process standards have the same characteristics as CMMI, and 
although not required, such standards do provide an additional tool in the toolbox 
for enterprises that are embarking on a long-term journey towards better 
business outcomes and improved business agility. 

For more information about CMMI, see: 
http://www.sei .cmu.edu/cmmi/ 
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Governing change 


Throughout this book, we explain the need to optimize the process of change. In 
this chapter, we address how to govern change effectively throughout the 
enterprise landscape. 
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8.1 Sources that drive change 


There can be many different sources driving change, different tribes that have the 
need and right to initiate change, and different life cycles through which change 
needs to propagate. Consider the following few examples: 

► As the result of a strategy change, enterprise planning outlines the need to 
standardize the sales organization and sales concepts for all geographies. 
This change in the enterprise architecture needs to be filtered through a 
portfolio management lens to determine the operational processes that are 
impacted by the change. Finally, multiple projects will be initiated to 
implement the most critical changes. 

► From monitoring operational processes, a business process management 
(BPM) initiative recognizes that the sales force in North America is spending 
more time on paperwork than on customer contact. As a result of that 
realization, a project is initiated to orchestrate and automate the most time 
consuming administrative processes to ease the administrative burden on the 
sales force. This might or might not lead to a change in the EA blueprints for 
good sales practices. 

► A project working on an ATM solution realizes that the enterprise blueprint 
that they have been using did not take into account the latency of ATM 
networks. The project needs to change their design of the solution, deviating 
from the enterprise blueprint, to achieve appropriate response times. Most 
likely, this change will not result in any change of the Enterprise Architecture 
(EA) blueprint because the blueprint by definition is channel agnostic and 
applicable to many different solutions throughout the enterprise. The ATM 
solution is simply an exception from the rule. 

As shown in these examples, the detection and management of change 
throughout an enterprise is a dynamic process, and because the enterprise 
landscape is not hierarchical, EA does not always win. To provide structure to 
this dynamic change environment, governance procedures are needed to ensure 
that the right decisions are made at the right time for the right reasons, based on 
appropriate information. 


8.2 Business agility and enterprise governance 

Although striving for business agility is an imperative for most modern 
enterprises, ungoverned change is not always good. Without any kind of formal 
decision responsibility and without appropriate controls in place, change tends to 
be uncoordinated and chaotic, often leading to unintended side effects. In fact, 
achieving continuous business improvement through collaborative and integrated 
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planning and delivery processes throughout the enterprise (business and IT) is 
difficult to imagine without applying “just in time and just enough” governance in a 
robust and collaborative fashion. 

The objective of governance is to establish chains of responsibility, authority, and 
communication with the purpose of empowering people to make the right 
decisions at the right point in time. With embedded measurements and policy 
and control mechanisms, this enables an agile enterprise to establish and apply 
enterprise-level guidance towards common objectives, rather than allowing 
suboptimization of decisions due to local goals and concerns. Furthermore, 
appropriate governance can prevent simple mistakes and can help ensure 
compliance with legislation and corporate regulations. 

EA, through transition planning and architectural governance, governs change 
across the gap between enterprise planning and solution delivery. That is well 
understood as part of the classical EA discipline. EA and EA governance on its 
own, however, is ineffective. You need a more holistic approach to enterprise 
governance that builds on the strong synergies between EA, BPM, and 
service-oriented architecture (SOA) and that reaches from strategy to 
deployment and operations. 

Traditionally, business governance and IT governance have been perceived as 
separate concerns, but for enterprises that are dependent on IT enablement of 
business capabilities, such separation is not adequate for governing agile 
change. BPM and SOA governance close the gap between business governance 
and IT governance as illustrated in Figure 8-1 . 


Figure 8-1 Closing the gap between business governance and IT governance 

Making sure that appropriate approvals and controls are in place when 
arrangements or procedures are modified has always been integral to a robust 
business operating model. Conversely, governing change at the solution level for 



Governing organizational change 


Governing the portfolio of 
business processes and services 


Governing changes to BPM and 
SOA solutions 
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combined business and IT solutions is often not recognized by business and IT 
leaders as critical or is even confused with resource-level governance. Resource 
governance is not a proper substitute for governing change. Both types of 
governance are needed, yet there is a distinct difference between the two: 

► Resource governance is focused on governing the progressive evolution of a 
single resource. 

► Change governance is focused on governing the chaotic structure of 
interrelated projects, development tasks, bug fixes, and operational 
adjustments throughout the enterprise. 

Focus in the IT industry remains (for now) mainly on the classical notion of 
managing resources in a repository or registry, not managing and governing 
holistic solution change. This discrepancy between the business need for 
managed and governed end-to-end change processes and the tool- and 
repository-centric IT approach to development and operations is a significant 
stumbling block for business and IT convergence in support of agile change and 
continuous business improvement and is a challenge that must be overcome on 
the journey from tribes to nations. 


8.3 The business need for end-to-end change processes 

The distinction between resource governance and change governance might be 
considered artificial and unnecessarily complicated. For a long time, the IT 
industry has been focused mostly on resource management and governance, 
driven by the need for providing efficient repository infrastructures. Yet from a 
business perspective, the management and governance of change is the main 
issue of importance. How that change is achieved through a multitude of 
resource-level changes is almost irrelevant. 

As a simple example from the business world, consider an order to a 
communications services provider. Does it matter to the customer how that order 
is realized through network settings, switches, cables, and software, or does it 
matter that the result is the provisioning of cable TV, phone, and Internet quickly? 
From a business perspective, the net effect of the order realized in terms of 
services provided is the only thing that matters, not the resource changes that 
were necessary to achieve the result. 

In the business world, it is self-evident that uncontrolled change can lead to 
chaos. Unauthorized persons can make harmful changes, unreviewed incorrect 
changes might slip into the system, and negative situations cannot be recovered 
or rolled back. One example of how these risks increase in importance and 
impact in a business-led agile environment is the recent case where an Internet 
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store accidentally capped everything at a price of $49.95 and lost $1 .6 million in 
a matter of hours before the error could be detected and corrected. 


The more agile the solution, the more control placed in the hands of the 
business, the more critical change governance becomes. The pricing mishap 
might have been avoided if a governance procedure defined that all such 
changes must be reviewed by at least two people before being activated. 

Classically, the IT industry has sharply distinguished between development and 
operations and has seen change in the context of either one or the other. Yet with 
the emergence of SOA as a dominant architectural style and with the additional 
dynamic business change aspects brought by BPM as a discipline, that line 
quickly blurs. Many business organizational changes are operational in nature 
and do not require development in the traditional sense. Also the behavior of 
many services can be adjusted by changing runtime policies. Add to that the 
concept of BPM, where business processes and activities have built in agility 
points that allow dynamic changes to take effect in near real time. In such an 
environment, agile changes occur continuously, and those changes certainly 
should be properly managed and governed as witnessed by the examples that 
we described previously. 

What does all of this mean for a modern enterprise? It means that there are clear 
business benefits to monitoring end-to-end change processes and governing 
those processes across the converged business and IT space, all the way from 
inception of a change through deployment and follow-up. Supporting agile 
business-led change has significant business value, but only if such change 
happens intentionally and in a controlled fashion. How do we achieve that result 
effectively? By applying BPM to the business of change to define, optimize, and 
orchestrate the change process itself, tracking and managing changes all the 
way from strategic intent through solution delivery. 


8.4 From resource governance to change governance 

Let us consider more closely the notion of governing an end-to-end change 
process and how this differs from a more traditional resource-centric point of 
view. 

Any artifact or resource in and of itself has a life cycle from creation through end 
of life. During its life cycle, a resource exists in many different revisions, with each 
revision being the result of authoring and applying a change. Resource 
governance has a single resource as its root object and is the process of 
governing decisions on that resource throughout its life cycle, independently of 
external context. 
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In contrast, change governance has as root objects those various contexts in 
which change is applied. Specifically, a change context is an anchor point for a 
series of changes against a current state. A change context has the following 
characteristics: 

► Has a particular purpose (such as a large project, a small development task, 
a bug fix, a runtime policy adjustment, or other undertakings) 

► Exists within a particular one of the three life cycles in the enterprise 
landscape (but can trigger cascading changes impacting other life cycles) 

► Defines the current (portfolio or planning) state that is the foundation for 
change 

► Records all resource changes (typically multiple) that are done to fulfill the 
purpose 

As illustrated in Figure 8-2, a change context has its own life cycle that is 
independent from the resources that are affected. That life cycle (whether 
measured in minutes or years) ends as soon as the purpose of the change is 
either completed or is abandoned. 



Figure 8-2 Tracking multiple related resource changes in a change context 

The result of a change context life cycle, if not abandoned, is a new current state 
of the solution portfolio or possibly of the enterprise architecture. Contrast that 
with a resource life cycle where it does not really make sense to talk about a 
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result. When the resource life cycle has ended, the resource is no longer 
available and only historical traces remain. 

It is worth noting that not everything in a completed change context ends up in 
the new current state. Often helper artifacts, such as intermediary work products, 
change context-specific requirements, and so on, are thrown away when the 
change context completes. 

Although the resource life cycles and the change context life cycles are distinct 
and non-related, it can often be necessary to shield the resource changes done 
within a change context from anyone outside that change context because 
changes within the change context have not been committed to the solution 
portfolio yet. In practical applications, this means that change context revisions of 
resources should be visible only to people and resources within that same 
change context. There are different ways of achieving this result, ranging from 
segmenting of a linear version history to full-blown branched development. The 
particular mechanism that is used is not important as long as the desired lines of 
visibility are maintained according to a parallel evolution pattern. 


8.5 Governing SOA and BPM change 

Analysts and vendors have invested time and attention in SOA governance for 
years. In most cases, however, the marketplace has not recognized clearly that 
SOA governance and service governance are two different things. Although 
service governance is part of SOA governance, SOA governance includes more 
than that. Service governance is in reality service resource governance. SOA 
governance adds planning and portfolio aspects and must include change 
governance as a key component. 

The term BPM governance is less commonly used. BPM governance is defined 
as governance of the end-to-end business processes in an enterprise. Similar to 
the distinction between SOA governance and service governance, we can 
like-wise talk about BPM governance and process governance. Process 
governance is process resource governance. BPM governance adds planning 
and portfolio aspects, and must include change governance as a key component. 

Because of SOA and BPM synergies and dependencies, it is necessary to 
consider change governance holistically across BPM and SOA. Furthermore, 
change governance in a BPM and SOA environment must include things such as 
organizational changes, because no process executes properly in an 
organization that it does not fit. 
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For more information about SOA and BPM synergies and dependencies, see the 
IBM white paper Achieving business agility with BPM and SOA together: Smart 
work in the smart enterprise, which is available for download at: 
ftp://pubfic.dhe.ibm.com/common/ssi/ecm/en/wswl4078usen/WSW14078USEN.PDF 

As explained previously, managing and governing end-to-end change processes 
is of critical importance to an agile enterprise. A good and scalable way to embed 
appropriate governance in an end-to-end change process is to inject the 
necessary governance decisions as activities or subprocesses, as illustrated in 
Figure 8-3. 


E2E change process 




Policy enabled gov. decision process 

□ o 


Read 



Figure 8-3 Governing end-to-end change processes 


Different types of change of course need different end-to-end change processes 
with different levels of governance. Some governance decisions will be 
policy-enabled and partially automated and others will be purely human 
decisions. Changing a policy perhaps needs lightweight governance embedded 
in a simple change process, while re-engineering a critical process needs much 
higher degrees of governance, quality assurance and staged deployment. The 
level of variance can be quite high, yet by applying dynamic BPM capabilities to 
the process of change, such variance becomes manageable. In the context of 
BPM and EA synergies, note how change governance decision points in turn can 
and should also serve as EA governance collaboration and control points. 
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At the heart of continuous business improvement is, as we explained previously, 
the proper balance of organizational effectiveness and operational efficiency. 
Although resource-level governance to some degree can support operational 
excellence, managing and governing change explicitly is a key enabler for 
long-term organizational effectiveness. The classical approach of driving change 
only through structured development does not scale well in a large modern 
enterprise, nor does it facilitate the critical EA and BPM synergies being 
explained throughout this book. End-to-end change processes must be flexible 
and adaptable to the type of change in question. Business processes and 
solutions need to be dynamically adjustable after deployment to support agile 
and dynamic change. Parallel changes need to be coordinated and conflicts 
reconciled. Organizations, processes, and services need to evolve in lock-step to 
maintain business integrity. In summary, change governance is not a choice for 
agile market leaders: it is a necessity. 
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9 


Effective enterprise 
collaboration 


We have consistently argued that it is important to realize the value of doing 
business process management (BPM) and enterprise architecture (EA) in a 
synergistic fashion. Only when supported by appropriate collaboration and 
governance processes can BPM and EA roles work effectively towards the 
common goals of the enterprise. 

In our journey through the enterprise landscape, we now arrive back in the 
21st century and need to bring together all the pieces required for a nation to be 
formed from a set of disparate tribes. The key to bringing together EA, BPM, 
governance, portfolio management, and architecture is effective enterprise 
collaboration. Interaction in an enterprise obviously happens on a daily basis, but 
not all interaction constitutes collaboration and not all collaboration patterns are 
equally effective for a given task. 

In this chapter, we elaborate on the enterprise landscape, focusing on the types 
of tasks that are intrinsic to that landscape and the collaboration patterns that 
enable effective interaction. 
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9.1 Refining the enterprise landscape 


The tasks that are performed throughout the enterprise landscape can be 
categorized into activity types, such as conceptualize, analyze, design, construct, 
and deploy, which can be applied to different types of artifacts. The reason for 
enumerating these activity types explicitly is that if we do not understand each 
others work processes, then I might be talking about analyzing something, and 
you might be talking about building that same thing, with obvious opportunities 
for misunderstandings and non-effective collaboration. 

The life cycles that are defined as part of the enterprise landscape (in Figure 1-5 
on page 10) provide context and reason for the various types of activities. In 
addition, we need to explicitly identify the kinds of activities that make sense to 
perform within a life cycle, while at the same time formally defining the full set of 
activity types, as illustrated in Figure 9-1 . 



Figure 9- 1 Activity types mapped to life cycles 


Any activity within the enterprise landscape should be an instantiation of exactly 
one of the activity types (disregarding support activities such as testing) and 
exactly one of the life cycle types. If such a mapping is not possible, it is 
appropriate to question whether one really knows what the activity is for and 
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about. Without this rigor in applying the enterprise landscape, its full value in 
support of the journey towards an integrated enterprise cannot be realized. 


Note that “level of abstraction” is not part of the classification of an activity. Level 
of abstraction might be a pre- or post-condition for a given activity but is not a 
substitute for the activity (type) itself. A given version of an artifact can pass or fail 
certain level of abstraction conditions, meaning that it can be used for certain 
activities and not for others. Yet the artifact itself does not have the level of 
abstraction as an intrinsic part or property of its classification. Indeed the same 
artifact (in different versions) can fail or pass different level of abstraction 
conditions at different points in its life cycle. 


9.2 Defining enterprise collaboration patterns 


Having defined both life cycles and activity types, we can now talk about different 
types of collaboration and where each should be applied within the enterprise 
landscape. In general, collaboration types can be grouped into three different 
collaboration patterns. 

The first of these collaboration patterns, synchronous sharing, is also the 
simplest, as illustrated in Figure 9-2. 


In the synchronous sharing collaboration pattern, everyone works directly on the 
same artifacts and all committed changes are visible to everyone immediately. 
There is no change control mechanism beyond the synchronous sharing of the 
same model and possibly some kind of notification mechanism that alerts 
practitioners to changes. Thus, this collaboration pattern is relevant mostly for 
small groups working within a single domain. 


Artifact changes from different practitioners 
(working directly on the shared artifacts) 



Figure 9-2 Synchronous sharing: Direct collaboration pattern 
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The second collaboration pattern, parallel evolution, is perhaps the most well 
known, has been applied within software development for decades, and is well 
described in industry literature. See Figure 9-3. 



In the parallel evolution pattern, local work is isolated from other (parallel) 
changes and is not visible to practitioners who are outside the local context until 
the work is merged with the main portfolio of artifacts. When initiated, local work 
is seeded with existing artifacts that need to be changed. When completed, 
changes are compared to the latest (shared) repository version and merged back 
into the portfolio context. An enterprise policy decision typically determines how 
many levels of parallelism to support and which mechanisms to apply for seeding 
and merging. 
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The third collaboration pattern, target and feedback, is as important as the other 
two but is rarely talked about in any formal sense. This pattern is appropriate for 
any kind of architectural governance. As an example, Figure 9-4 shows the 
collaboration across enterprise planning and solution delivery life cycles. 



In the target and feedback collaboration pattern, work in one context sets targets 
for work in a different context. 

A defined target (standard, pattern, and so on) is intended to be honored by 
solution delivery artifacts. Targets (new or changed) are often activated through 
raising change requests downstream or through some kind of publishing 
mechanism. It is a policy decision as to when each local delivery effort must 
conform to the higher level target models. 

Feedback is an important part of the target and feedback pattern. After the target 
has been applied to one or more solutions, it is crucial that feedback is provided 
from the solution delivery life cycle in the following manner: 

► How well was the solution able to comply with the targets? 

► Are there suggestions on how the target might be improved for future use? 
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The first type of feedback allows the enterprise planning tribe to monitor progress 
and compliance. The second type of feedback allows the enterprise planning 
tribe to selectively (if they agree with the suggestion) adjust their architectural 
targets based on real experience with using them. Note that it is the enterprise 
planning tribe that decides whether to apply suggested changes. If the enterprise 
planning tribe disagrees, they will throw away the suggestion; this is one of the 
subtle but important differences between the target and feedback pattern and the 
parallel evolution pattern. If the enterprise planning tribe decides to accept the 
suggested changes, the updated targets (standards, patterns, and so on) can in 
turn (if important enough) be applied to other ongoing solution delivery efforts. It 
is a policy decision when to cascade to how many ongoing solution delivery 
efforts. 

Model transformations are virtually never applied across the life cycle boundaries 
that are involved in the target and feedback pattern. The targets are used as 
references, not as solution seeds. Changes across the planning and delivery life 
cycle boundaries are coordinated but are not synchronized. It is legitimate that a 
solution does not 100% fulfill an architectural target. This simply constitutes an 
exception and is handled as described in 3.3, “Integrated strategic planning” on 
page 41 . When to coordinate changes and at which point in the individual life 
cycles is an important design point for architecture governance processes and 
procedures. 

At a minimum, targets should be set at the beginning of a solution delivery 
project and feedback should be provided at the conclusion of a solution delivery 
project. More frequent coordination might be desirable, depending on the nature 
of the targets and solutions that are involved. Also, some enterprises scale 
architectural governance by applying enterprise planning targets not just to 
projects but also to the portfolio of existing assets. Coordinating with the portfolio 
management life cycle in this manner is an excellent way of ensuring synergistic 
collaboration between, for example, enterprise architects and process owners. 

To better understand the target and feedback pattern, a real-world analogy is one 
of city plans, building codes, and skyscrapers: 

► The city plan is engineered in an enterprise planning life cycle, laying out the 
desired future state and standards of the city. 

► Building codes (targets) are established to regulate the way individual 
buildings are built according to zoning and purpose. 

► Skyscrapers are constructed in multiple solution delivery cycles, each of 
which applies the building codes. Occasionally, a builder might need approval 
for building code exceptions. 

A change in the city plan can impact the building codes that apply to a particular 
skyscraper, which can result in changes in skyscraper construction. In addition, 
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city policy defines timelines, enforced level of compliance, and other governance 
parameters that are related to building codes. An example of feedback that can 
change the building codes is new knowledge gained as a result of failures in 
constructed buildings. 

Note that some building codes are mandatory (for example, based on 
legislation), and other building codes are advisory in nature (for example, based 
on aesthetics). This point illustrates that not all targets are absolute. Thus, an 
important aspect of understanding how to apply an architectural target is 
understanding the degree of enforcement that is related to it. 


9.3 Collaboration through linking and cloning 

In Chapter 6, “Stop copying; start linking” on page 83, we explained the 
advantages of linking versus copying. Now, we need to understand how a linking 
approach can support our three defined collaboration patterns: 

► Direct collaboration: No linking or cloning is needed; the current version is 
always used. 

► Parallel evolution: When a parallel context is branched off from the main 
stream of modeling artifacts, a clone is created for any artifact that is changed 
within that parallel context. It is a clone and not a copy, because it has its own 
identity (in this case a different version) and is linked to the original (in support 
of a later three-way compare and merge). 

► Target and feedback: Generally, targets are linked to the solution delivery 
artifacts to which they apply in order to support traceability and coordination 
of changes. In some cases, the target might be cloned to seed a new solution 
delivery artifact. In such cases, the new artifact is not a new version of the 
target but is a completely different artifact with its own independent life cycle. 

None of these collaboration patterns require copying. In fact, copying breaks the 
collaboration patterns due to loss of traceability and transparency. This 
observation is consistent with the fact that copying breaks three of the principles 
of actionable architecture in that the context is lost, there is little collaboration 
between the tribe working with the original and the tribe working with the copy, 
and the copy is disconnected from the original. 


9.4 Best practices for applying collaboration patterns 

Having defined the vocabulary for life cycles, activities, and collaboration patterns 
throughout the enterprise landscape, we can now provide preferred practices for 
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where and when to apply which collaboration patterns. In general, collaboration 
can occur across the following types of boundaries: 

► Life cycle boundary 

► Resource domain boundary (for example, across processes and services) 

► Activity type boundary (for example, across analysis and specification) 

Depending on the particular boundary that is crossed, consider using the 
collaboration patterns as listed in Table 9-1. 


Table 9- 1 Collaboration patterns 


Situation 

Collaboration pattern 

Collaboration across enterprise planning 
and solution delivery 

Target and feedback 

Collaboration across portfolio 
optimization and project 

Parallel evolution 

Collaboration within enterprise planning 

Synchronous sharing 

Collaboration within a single resource 
domain and single activity type 

Synchronous sharing 

Collaboration within a single resource 
domain and across activity types 

Synchronous sharing or target and 
feedback 

Collaboration across resource domains 

Target and feedback 


Given that simultaneous collaboration across multiple boundaries is an 
anti-pattern to be avoided if possible, this list of situations is exhaustive. Note that 
the guidance that we provide is independent of whether collaboration occurs 
inter-enterprise or intra-enterprise. 

The case with collaboration within a single resource domain and across activity 
types is the only situation that has a “depends” guideline. The reason for this is 
that, depending on whether the actual situation concerns an elaboration of the 
same logical construct or concerns one construct that is a requirement for 
another (for example technology independent specification and 
technology-dependent realization), consider using different collaboration 
patterns. Typically the exact methodology that is applied triggers one or the other 
across a given boundary. Thus, choose carefully the collaboration pattern that fits 
the methodology. 
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Actual collaboration within or across life cycles and activities requires that one or 
more tribes are involved. Consequently, to apply these guidelines, we need to 
understand how the tribes of the enterprise map to the enterprise landscape. 
Figure 9-5 shows an example for a fictitious enterprise environment. 



Figure 9-5 Mapping the tribes of the enterprise 


Figure 9-5 is only an example. No generic mapping exists. Each enterprise must 
analyze and map its own particular roles and tribes onto the enterprise 
landscape. 
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Part 3 


A worked example 


In the first two parts of this book, we explained concepts and methods that allow 
enterprises to effectively and synergistically collaborate across business process 
management (BPM) and Enterprise Architecture (EA) boundaries. Furthermore, 
we presented that such collaboration is a necessity for organizations that want to 
move towards better business outcomes. 

In this part of the book, we provide an example of how to link and optimize the 
planning life cycle using EA capabilities and the solution delivery life cycles using 
BPM capabilities. Our example is based on a fictitious company called JKHL 
Enterprises, which provides financial and banking services to customers globally. 

JKHL Enterprises provides banking services to customers. The bank provides 
various services through online, branch, and telephone offerings. These services 
differ based on the geographies within which the company operates. Where 
possible, the bank wants to standardize both its process and IT infrastructure and 
re-use as much of this infrastructure as possible to reduce cost and improve 
quality. 

JKHL Enterprises has an enterprise architecture capability that provides strategy 
and guidance on enterprise-wide architecture initiatives. The bank also actively 
manages the portfolio of business processes, monitoring operational 
performance against well-defined key performance indicators and applying BPM 
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to those processes that need to be improved. The BPM and EA teams work hand 
in hand to ensure better business outcomes for the enterprise as a whole. 

This part includes the following chapters: 

► Chapter 10, “EA applied” on page 121 

► Chapter 1 1 , “BPM applied” on page 147 

► Chapter 12, “Linking EA and BPM artifacts” on page 163 

► Chapter 13, “Four select collaboration scenarios” on page 173 

If you are interested only in information about how to link, go directly to Chapters 
12 and 13. You do not need to first read Chapters 10 and 1 1 . 

Although our worked example does not map out a complete enterprise 
architecture for JKHL Enterprise or a complete BPM portfolio or solution, it does 
use a big enough subset of EA and BPM work products to demonstrate how the 
EA and BPM disciplines are linked in practice and how changes are managed 
across their collaborative boundaries. We use current IBM tools to provide the 
screen captures and graphics in the example, yet the set of techniques and work 
products that are applied can be instantiated on any mainstream BPM and EA 
tools that support link-based collaboration patterns. 


120 


Combining BPM and EA for Better Business Outcomes 



10 


EA applied 


This chapter applies enterprise architecture as a discipline to the JKHL 
Enterprises example. The elaborated example is not complete, but provides a 
slice through typical EA work products. Although we use current IBM tools to 
produce screen captures for this chapter, what is shown could have been 
produced with other mainstream EA tools. 

Note that all work products in this chapter are enterprise planning work products, 
meaning that they are to be thought of as either representing current state or 
representing some future target state. The only way to execute on the desired 
changes is to apply the EA targets to ongoing or future solution delivery 
activities. If the EA targets are not achieved in the near future, no operational 
breakages or immediate inefficiencies will occur. However, it might result in less 
profitability over time or even potentially a disruptive business failure if JKHL 
Enterprises fails to adapt to critical market movements. An example of the latter 
is the US auto industry that was optimizing (successfully) for an environment 
where SUVs were the obvious cash cow, only failed to react in time as the auto 
market shifted to focus on smaller and more fuel efficient cars. 
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10.1 Business architecture 


The first EA domain within which the JKHL Enterprises example is elaborated is 
business architecture. 


10.1.1 Business motivation model 

JKHL Enterprises decided at a strategy meeting that the company needs to 
increase cross selling of its product portfolio to existing customers. To increase 
market share, the company needs to increase the average spend of its 
customers. The business motivation model (sometimes called an Enterprise 
Direction Diagram) provides a description of the strategy and the goals of the 
enterprise. Figure 10-1 on page 123 illustrates the current strategies, tactics, 
direction, and objectives of JKHL Enterprises. 
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JKHL Enterprises 



Figure 10-1 Business motivation model 


One goal of the organization is to gain market share. In addition, a new objective 
has been added to the model, Upsell Products to Existing Customers, which is 
related to the goal of gaining market share. 
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10.1.2 Organizational chart 


The organizational structure of JKHL Enterprises can be represented in an 
organizational chart, as shown in Figure 10-2. The organizational chart 
represents the organization as a whole and can be decomposed into more 
focused organizational charts. 


I 


Commercial 


Commercial I 
Sales | 


- 

L 


CommerciaTj 


Commercial I 
Credit | 


JKHL Enterprises 


Retail 

Sales 




I eBusiness I 
| Sales | 


- 

H 


eBusiness 


eBusiness 

Credit 


Executive Management 


• Operations Resourcing 

• Operations Planning 

• Operations Management 

• Operations Continuity 
Planning 

• Legal Executor 

• Information Manager 

• Financial Strategist 

• Financial Advisor 

• Entreprenuerist 

• Business Visionary 

• Business Strategist 


Figure 10-2 JKHL Enterprises organizational chart 


The organizational structure also contains the actors who are associated with the 
organizational units and any skills or competencies that are required to perform a 
particular role. Skills in particular might be impacted by the new up-sell objective. 
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10.1.3 Functional hierarchy 


The functional hierarchy shows the major business functions that exist inside the 
organization, as illustrated in Figure 10-3. The business functions describe the 
types of operations that JKHL Enterprises carries out to support its banking and 
finance operations. 
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We can identify and extract the subset of business functions that potentially can 
be affected by the up-sell objective, such as the subset illustrated in Figure 10-4. 
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10.1.4 Business services 


JKHL Enterprises provides a set of business services that provide specific 
capabilities for the business and its partner network, as illustrated in Figure 10-5. 
The business services are explicitly defined with an interface to the outside world 
and are governed by JKHL Enterprises. 







Figure 10-5 JKHL Enterprises business services 


Figure 10-5 shows that a new business service, Provide Customer with New 
Product Options, has been added to the future state EA model. This will be a 
self-contained service that provides a necessary capability to support the new 
business objective. 
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10.1.5 Business service to actor mapping 

A business service has interactions with actors. The actors are the consumers of 
the business service. In the JKHL Enterprises scenario, the Customer Services 
Representative and Sales Manager actors interact with the Provide Customer 
with New Product Options business service, as illustrated in Figure 10-6. These 
relationships are used to identify the organizational impact of the desired 
changes and to plan accordingly in advance. 



Figure 1 0-6 Business service and its actors 
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10.1.6 Business process hierarchy 


A business process hierarchy in an EA context provides a blueprint view of the 
types of process the organization should conceptually support. Figure 10-7 
shows the JKHL Enterprises business process hierarchy in catalog form. The 
business process type named Process Banking Transaction needs to be 
instantiated by actual process blueprints. 
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Reconciliation 


Figure 10-7 JKHL Enterprises business process hierarchy 
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10.1.7 Business processes 


Figure 10-8 illustrates the EA process blueprint that provides guidance for 
processes that are related to banking transactions. 



Remember that this is not a process model in the business process management 
(BPM) sense, but instead it is a target or pattern that will be applied to any 
operational process that has to do with banking transactions (of which there are 
typically many). One of the key steps in applying the process blueprint is to first 
identify the operational processes (in the process portfolio) that are in scope for 
the blueprint. For more information, see Chapter 13, “Four select collaboration 
scenarios” on page 1 73. 

The model in Figure 10-8 characterizes how an organization might generically 
put into practice the process of managing a customer transaction. It provides a 
set of guiding principles for how any customer transaction process should be 
implemented, not a design for a particular implementation. A particular customer 
transaction process can be realized manually, electronically, or in a combination 
of both, depending on the implementation circumstances; such implementation 
choices are not part of enterprise planning. 

The “target” process blueprint is enhanced to support the objective of providing 
customers with product up-sell options when they need to complete a banking 
transaction. The operational channels upon which such an enhanced “target” 
must be applied (through architectural governance) can include online banking, 
branches, and telephone banking. There can also be regional differences in 
legislation or IT capabilities, which means that there can be many different 
operational processes, all partaking in the portfolio optimization life cycle, but 
none of them a direct concern of EA. 
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Modeling the enhanced process within EA helps to understand what needs to 
change in other parts of the enterprise architecture in response to the change in 
the process blueprint. Figure 10-9 highlights that the enhanced process blueprint 
requires an input from product/services catalog data. To complete the example, 
we would also connect the enhanced process blueprint to the new business 
service, Provide Customer with New Product Options, thereby documenting the 
change dependency between the two. 



Another part of the EA analysis is the consideration of alternatives. Figure 10-10 
shows an alternative that provides a chance to change the existing product 
portfolio for a customer in addition to adding new products. Alternatives can be 
compared both with respect to how well they support the new business objective 
and with respect to how much enterprise change each alternative will require. 



Figure 10-10 Enhanced banking transaction process blueprint with product modification 
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10.2 Data architecture 


Having elaborated the business architecture for the JKHL Enterprises example, 
we turn next to the data architecture domain. 


10.2.1 Class diagrams or entity relationship diagrams 

Different modelers of data require different views or viewpoints and different 
modeling and visualization styles, such as UML Class diagrams or Entity 
Relationship diagrams. In the JKHL Enterprises example, the data model in 
Figure 10-1 1 shows the Customer, Contact History, Contact Record, and 
Financial Product data (in UML Class diagram form), all of which are required as 
input to the enhanced process blueprint shown in Figure 10-9 on page 131 . 



Figure 10-11 UML Class view of data 
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Figure 10-12 shows the same data model in entity relationship diagram form. 



Figure 10-12 ERD view of data 


Some tools (such as the IBM EA tool) can show either view based on the same 
underlying model. Other tools use two different models for the two different 
representations. 


10.2.2 Linking data into the rest of the enterprise architecture 

An important aspect within the enterprise architecture is to link the data artifacts 
to the rest of the EA model to show data impacts when performing architectural 
analysis. Typical dependencies are data element to business service, data 
element to process or activity, data element to role, data element to technology, 
data element to application, and data element to data object providing that data. 
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Figure 10-13 exemplifies this by showing that the Financial Product data element 
is used by the Product/Services Catalog data object (which in turn was needed 
for the enhanced process blueprint). 



Figure 10-13 Data linkage 


10.3 Application architecture 

Following the elaboration of the data architecture, next we consider the 
application architecture domain. 

10.3.1 Logical application components 

Within the application portfolio, we can lay out blueprints for both physical 
application components and logical application components: 

► A logical application component is an encapsulation of application capability. 
The application capability is independent of its implementation 
characteristics. 

► A physical application component is the realization of a logical application 
component, typically an existing application. 
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Figure 10-14 shows that a Product Catalog and Inventory system is required and 
that it needs to read information from a product details repository/database. This 
new capability is required to support JKHL Enterprise’s ability to offer the 
products from the enterprise product portfolio to existing or new customers. 
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Figure 10-14 JKHL Enterprises logical application component view for sales 


10.3.2 Harvesting the application portfolio 

Before investing in new applications, JKHL Enterprises can make an assessment 
of the current applications. There are a number of mechanisms for harvesting the 
portfolio of applications. The inventory of applications can exist in spreadsheets 
that are maintained by hand or in databases that are maintained by tools. Many 
organizations use a Configuration and Change Management Database 
(CCMDB) to catalog operational assets. Alternatively, it is possible to harvest 
existing applications by looking at the ERP implementations, such as SAP, to 
determine the application components that are available and in use. 

Often associated with physical application components in the current state 
enterprise architecture are temporal properties, such as “In service date” and 
“Retirement Date.” Owners, costs, and other physical information is usually also 
stored with a physical application component. Furthermore, many vendors 
supply application component road maps, and organizations can inject these 
road maps into their EA model to determine the capabilities that are available at 
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a given future date and how these capabilities fit with other aspects of the 
expected future state at that date. 

Figure 10-15 shows the plan for two new physical applications that provide the 
capability to manage catalogs of products and service offerings. 



Figure 10-15 JKHL Enterprises physical application portfolio 
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Figure 10-16 shows the relationship between the logical application component 
and the physical realizations. The logical Product Catalog and Inventory 
application is realized through two physical real-world applications: 

► Product Inventory Tool (PIT) 

► Catalog Manager 



Figure 10-16 Physical instantiations of the logical application component 


It is important to remember that none of the EA application component diagrams 
represent actual delivery of any applications or application changes. They are 
simply statements of desired or required changes to realize some defined future 
state of the enterprise. 

10.3.3 Mapping applications to business services 

The logical application components can be mapped to business services to show 
how a business service is supported by IT capabilities. Figure 10-17 shows that 
the business service Provide Customer with New Product Options is enabled by 
the Product Catalog and Inventory logical application component. 


Provide Customer with New Product Options 


Product Catalog 
and Inventory 


Figure 10-17 Business service to logical application component mapping 
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10.3.4 Technology components 

Technology components describe the types of technology that are used in the 
organization. Both logical technology components and physical technology 
components can be used. For example, a telephone is a logical technology 
component that provides a specific technology capability. A physical component 
instantiating this might be a mobile phone with General Packet Radio Service 
(GPRS) characteristics. We can use a network concept diagram to lay out 
technology patterns and how we expect the technology to interact within our 
future state enterprise architecture. 

Figure 10-18 shows how the Customer Services Representative interacts with 
technology components within the banking infrastructure. The technology 
components need to be linked to other EA model elements. 
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10.4 Impact analysis 


Impact analysis allows JKHL Enterprises to see the various relationships 
between the elements of the EA model and to detect the impact that a change 
will have in terms of scope and complexity. 

Figure 10-19 shows the effect that the new business objective has as we slice 
across the architecture. For example, we can see the process that it impacts, 
because of the relationship between the process and the objective that it 
supports. We can also see which business services are realized by that process. 
Note that Figure 10-19 shows only one view across the enterprise architecture 
with a limited set of relationships. 
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We have not explained yet how links to solution delivery artifacts, such as BPM 
artifacts modeling operational processes, can aid cross-domain impact analysis. 
We explain this facet of impact analysis for the JKHL Enterprises example in 
Chapter 13, “Four select collaboration scenarios” on page 173. 

Analytics 

Impact analysis can be aided by analytics. For example, JKHL Enterprise can 
examine the business process blueprints to see which processes are customer 
facing and manual. By doing this, they can focus attention on the roles that 
perform such processes and increase competency levels to ensure that they 
have appropriate customer facing skills. See Figure 10-20. 
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Furthermore, JKHL Enterprises can use a role to competency matrix to specify 
the exact skills that are required for customer facing roles that are impacted by a 
planned change. Table 10-1 shows that the opportunity identifier is a new role in 
human-assisted transaction processes, a role that needs appropriate skills to 
support the up-sell goal. 

Table 10-1 Role to competency matrix 


Role 

j Competency 

Calmness 

Communication skills 

Methodical worker 

Numeracy 

Organizational 

Organizational skills 

Telephony 

Time management 

- 1 

Complaints Call Handler 

X 


X 



X 

X 


Complaints Clerk 

X 


X 




X 


Complaints Manager 

X 


X 



X 



- 1 

Opportunity Identifier 

X 

X 






X 

Personnel Management 


X 



X 



X 

- 1 


10.5 Transition planning 

EA target states reflect the available future state options within the EA model. 
However, not all of these will be implemented, and each set of options and their 
associated transition plans need to be assessed. JKHL Enterprises can use a 
series of techniques to differentiate the target states. We explain these 
techniques in this section. 
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10.5.1 Model differencing 


JKHL Enterprises can overlay model differences between target architectures by 
looking at a combined view of the two target states. For example, they can view 
model changes between the two alternative process blueprints that we described 
previously. In one target state, the model indicates to use a particular set of 
activities (which offers only new products to a customer), and in the other target 
state, the model indicates to do the process in a slightly different way (which 
offers a review of the existing products). Various views can be produced showing 
the model differences. 

The overlay of differences in Figure 1 0-21 creates a view that shows models from 
both architecture states overlaid on top of each other, so that differences can be 
seen visually in one view. 



Side-by-side differences, shown in Figure 10-22, allow model differences to be 
viewed where the layout of the model views differs in a way that cannot be 
understood when they are overlaid. 



Figure 10-22 Side-by-side differences 
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Differences can often also be viewed as a textual tree showing what has 
changed, similarly to using a word-processing capability to see document 
changes in a text document. 

10.5.2 Current state versus target state assessments 

Current versus target state assessments is a big topic, and one that we will touch 
only briefly in this elaborated example. 

Figure 10-23 illustrates that JKHL Enterprise can use intelligent dashboards to 
provide much of the information that is required for decision making about current 
versus target state architectures and transition plans. These dashboards can be 
based on cost, risk, resource, and other information. They can be applied 
throughout the different EA domains. Making a decision about which target 
architecture to choose is an important choice that needs to be made based on 
the best available information. 



Figure 10-23 “As Is” versus “To Be" Dashboard 
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10.5.3 Roadmaps 


After a future target state is chosen, JKHL Enterprises needs to make plans 
regarding the steps that are required to get to that future state. Road maps 
provide a view of the EA model over time and can provide a snapshot for any 
date of particular interest. Road maps can be laid out in many different ways. For 
JKHL Enterprises, Figure 10-24 shows the road map from a Sales function 
perspective. 



Figure 10-24 Nested table road map 
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An often preferred rendering of a road map is a Gantt chart style view, as shown 
in Figure 10-25. Although not as detailed as a textual description, the Gantt chart 
does provide a visual overview and shows the dependencies between various 
components that need to change. 
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11 


BPM applied 


This chapter applies business process management (BPM) as a discipline to the 
JKHL Enterprises example. The elaborated example is not complete but does 
illustrate a particular transaction-related process that is potentially impacted by 
the new business objective explained in Chapter 10, “EA applied” on page 121 . 
Because the work products that we use in this chapter are BPM work products, 
they all have solution delivery semantics and are related to improving the 
operational process that is the scope of the BPM example. Although we use 
current IBM tools to produce the screen captures in this chapter, what is shown 
could have been produced with other mainstream BPM suites. 

Successful BPM initiatives are business driven through iterative solution design 
and process improvement. Chapter 4, “BPM methods and tools” on page 53, 
introduced the IBM Software Services for WebSphere (ISSW) Solution 
Implementation Standard (referred to as ISIS) for BPM as a typical BPM method, 
and we could have simply rendered our BPM example in terms of the ISIS for 
BPM phase model. To emphasize the business nature of a BPM project, we have 
instead chosen to illustrate the BPM work products in the JKHL Enterprises 
example as they get created and used throughout the four typical steps 
experienced by business participants as illustrated in Figure 11-1 on page 148. 


© Copyright IBM Corp. 201 1 . All rights reserved. 


147 





Figure 11-1 Evolution of a BPM solution as seen from a business perspective 


The relationship to the phases of ISIS for BPM is not difficult to map out. For 
example, the discover step maps to the ISIS for BPM inception phase. 

For more information about these steps, see BPM Solution Implementation 

Guide, REDP-4543, which is available at: 

http : //www . redbooks . i bm . com/abstracts/redp4543 . html ?0pen 

Most well-run BPM projects have some level of built-in experimentation, either in 
the form of model simulation or in the form of repeated deployment, monitoring, 
and improvement based on monitoring results. We do not illustrate multiple 
iterations in our JKHL Enterprises example, those are simply implied. 
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11.1 Step 1 : Discover 

In this step, business intent is discovered, whether such intent is driven by an 
enterprise architecture (EA) target or by some other driver. Business intent is 
mapped to business capabilities and operational processes through the activities 
listed in Table 11-1. 

For more information, see BPM Solution Implementation Guide, REDP-4543. 


Table 11-1 Mapping business intent to business capabilities 


Detailed Activities 

Role 

Deliverable 

Identify business challenges 

Work with business leaders to determine 
which business challenges need to be 
addressed. Prioritize and assess the 
challenges and document them. 

Business leader and 
business analyst 

Document 

Strategize on solution 

Create strategies that are related to 
business challenges to determine their 
relationships to downstream goals and 
capabilities based on priorities. 

Business leader 

Strategy Map 

Define business/solution goals 

Identify specific, measurable goals to 
ensure that the solution is meeting the 
business needs. 

Business leader 

Strategy Map with Goals 

Define business measures 

Based on the identified strategy and 
goals, define business measurements, 
such as key performance indicators 
(KPIs), business service level 
agreements (SLAs), and metrics, that 
can be tracked and monitored 
periodically to ensure that the solution is 
meeting the specific business goals that 
are identified. 

Business leader 

Strategy map with 
Measures 

Define business functions 

Map out business functions, identify 
areas for process definition, and prioritize 
business functions based on business 
challenges. 

Business leader and 
business analyst 

Capability Map 
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Detailed Activities 

Role 

Deliverable 

Create high-level processes for high 
priority business capabilities 

Business leader and 
business analyst 

High Level Prioritized 
Process Maps 

Obtain executive sign-offs and approvals 

Ensure that executive level sign-off is 
achieved to proceed to the next set of 
phases. 

Business executive 

Business Sign Off 


Note that strategy and goals within BPM address either the process portfolio of 
the enterprise or a particular operational process. This is an important difference 
between the (enterprise) strategy and goals that are input to EA and the 
(solution) strategy and goals that are part of the output from BPM. The two types 
of objectives definitely cannot be substituted. 

Within the JKHL Enterprises example, there is an operational business process 
that handles online banking transactions in Germany. That process does not look 
exactly like the EA target defined in Chapter 10, “EA applied” on page 121 . In 
fact, it cannot look the same due to special German legislation and a localized 
SAP system with different capabilities than the enterprise standard. 

Nevertheless, the online banking process must be updated to reflect the new 
up-sell business objective, the business intent that is being applied to all 
customer facing transactional processes. One major change required on the 
current operational solution is to implement a connection to the SAP system to 
extract relevant customer data for up-sell analysis. Figure 11-2 illustrates the 
injection of this subprocess in the end-to-end transactional process. 



Figure 1 1 -2 Model the subprocess calling the SAP System 
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It is important that the new or changed online banking process is linked 
immediately to both the new business goal and the standard process target, 
which are both part of the EA model. The former is important because JKHL 
Enterprises needs to remember the business drivers for the change and needs to 
make sure that the new business objective remains in focus for future 
adjustments of the online solution process. The latter is important because every 
time JKHL Enterprises adjusts the online solution process, they need to get as 
close to the enterprise standard target as possible. After the links are 
established, they need to be maintained over time. 

See Chapter 12, “Linking EA and BPM artifacts” on page 163, for details about 
how to establish traceable links. See Chapter 13, “Four select collaboration 
scenarios” on page 173, for details about collaboration around future process 
changes. 


11.2 Step 2: Storyboard 

The storyboard step takes artifacts created in the discover step by one business 
analyst (or a small team) and shares them with a larger audience for further 
refinement and modifications. This step is especially important if BPM change 
flows from EA targets, because ultimately the BPM artifacts can be used for 
many lines of business (LOBs), and there will almost inevitably be some “not 
invented here” reactions. All stakeholders should get a chance to contribute to 
the BPM design during the storyboard phase to ensure quality and buy-in. Thus, 
scalable publication and commenting mechanisms are important in this step. See 
Figure 1 1-3 on page 152 for an example storyboard. 
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The storyboard step attempts to capture user impact by defining both as-is 
processes and to-be processes. Furthermore, operational business measures 
and KPIs should be defined (if not done during the discover step) and applied to 
the process model. Some of the measures and KPIs can be derived from EA 
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targets, and others might not be. Finally, mock up forms can be used to validate 
and visualize human interactions with the BPM artifacts. Figure 11-4 illustrates 
other examples of storyboarding. 
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Figure 1 1 -4 Other storyboard examples 


Table 1 1 -2 lists activities for the Storyboard step. For more information, see BPM 
Solution Implementation Guide, REDP-4543. 


Table 11-2 Storyboarding activities 


Detailed Activities 

Role 

Deliverable 

Capture/refine current state process 

Search for and import existing process 
model artifacts (BPM tools, Visio, 
PowerPoint, and so on). 

Search for reusable artifacts, such as 
business services and forms. 

If no reusable artifacts exist, begin to 
define the current state process from a 
blank slate. Keep the scope of the 
process in terms of the solution goals. 

Business analyst working 
with SME 

Current State Process 
Diagram 
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Detailed Activities 

Role 

Deliverable 

Examine alternate ROI to determine best 
approach 

Use case analysis to determine which 
usage scenarios/use cases best fit the 
goals that were defined during discovery 
and focus on defining those paths. 

Business analyst working 
with SME 

Case Analysis Reports 

Capture roles 

Capture all relevant human roles that 
perform steps in the process. 

Capture cost and duration information 
and associate them to the human steps in 
the process. 

Business analyst working 
with SME 

Future operational process 
with roles 

Define future operational process 

Define, simulate, and refine future 
operational business process models 
that achieve the closest results to the ROI 
alternative chosen from case analysis. 
Generate dynamic analysis reports to 
quantify/validate gains derived from 
future state process and support 
business case for implementation. 

Use design principals that include only 
portions of the model that are candidates 
for the end to end solution. Other 
modeling elements can be included but 
used only for documentation purposes. 

Business analyst working 
with SME 

Future operational process 
and Business Impact 
Report 

Identify process steps as candidates for 
business rules 

Identify steps in the process that are 
candidates for implementing business 
rules logic. 

Look for steps or multiple decisions that 
could be combined to create rules. 
Create simple rules. Rules can also be 
created to determine the appropriate 
staffing definition. 

Business analyst 

Future operational process 
with business rules steps 
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Detailed Activities 

Role 

Deliverable 

Define task inputs and outputs and mock 
up forms for human interactions 

Create business items that include 
business data and associate them as 
inputs and outputs to the various steps in 
the process. 

Generate simple form mock ups using 
forms designer based on the inputs and 
outputs for the tasks. 

Business analyst 

Future operational process 
with business items and 
mocked up forms 

Validate and visualize human interactions 

Perform storyboarding using simulation 
to validate with process owners the flow 
and content of the human steps within the 
process. Obtain sign off and approval to 
move to the experience phase. 

Business analyst working 
with SME and process 
owner 

Validated storyboards 


11.3 Step 3: Experience 

The experience step is where the BPM design is implemented and tested. This 
step includes adding operational characteristics and elaborating and refining 
business measures and KPIs. Additionally, the team can interactively test and 
validate elaborated executable processes in a sandbox before deploying to a 
shared enterprise environment. Figure 11-5 illustrates this step. 



Figure 1 1 -5 Interactively experience and visualize process 
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Table 1 1 -3 lists activities for the experience step. For more information, see BPM 
Solution Implementation Guide, REDP-4543. 


Table 11-3 Experience step activities 


Detailed Activities 

Role 

Deliverable 

Add operational characteristics to future 
operational process 

Refine and fill in high-level process steps, 
process logic, error handling, and data 
flow to support process execution. 
Process data reflects the fields and 
content that is needed to support the 
process from storyboarding. 

Business analyst and IT 
architect 

Process Models, Metric 
and KPI definitions, Role 
Definitions, and Form 
Mockups 

Define constructs for execution on future 
operational process 

Refine all process control flow (that is, 
gateways) to reflect decision logic based 
on process data. 

Define Business Object Model. 

Look for reuse opportunities. 

Map business roles for human tasks to 
the organizational directory. 

Add technical attributes to the process 
model to prepare for runtime deployment. 
Publish models to repository. 

Business analyst and IT 
architect 

Process Models, Metric 
and KPI definitions, Role 
Definitions, Form Mockups 

Elaboration of performance measures, 
KPIs, and business SLAs 

Introduce additional measures of process 
performance against the expanded 
operational process. This typically 
includes adding measures for activities, 
process branches, and other aggregated 
measures introduced during process 
refinement. 

Add task escalations in accordance to 
business SLAs. 

Business analyst 

New metric and KPI 
definitions 

Refine forms 

Working with Ul development, build out 
the form mockups as a fully functional 
user experience. 

Separate forms from the process 
application for separate development 
using a web-ready package for IT. 
Publish forms to repository. 

Business analyst, IT 
architect, and Ul developer 

Business user ready 
forms. Two options: 

► All packaged in a 
separate web-ready 
package 

► Imported back into the 
model project to 
replace the mockups 


156 Combining BPM and EA for Better Business Outcomes 






Detailed Activities 

Role 

Deliverable 

Interactively validate elaborated process 
in IT sandbox 

After adding operational characteristics 
for the first time or for subsequent 
iterations, the process model can be 
deployed (directly by LOB) to a sandbox 
environment for user interaction and 
validation. 

IT prepares sandbox test environment 
and registers test services for final 
experience validation using sandbox 
environment. 

A mockup can also be created of an 
appropriate business space for 
interacting with the process, which can 
provide guidance for IT. 

Business analyst and IT 
architect 

Optional: Exported 
Business Space mockup 


If change is driven by EA targets, as could be the case with JKHL Enterprises, it 
is important that the project continuously validates that the implementation is 
compliant with those EA targets to the extent possible. Practically, this is 
achieved using lookup of the EA artifacts that are already linked to the process. If 
EA targets cannot be met in practice, this might be an exception. See 3.3, 
“Integrated strategic planning” on page 41, for details about exception handling. 

It is in the experience step where BPM business process models are converted 
into actual executable process artifacts, typically based on Business Process 
Execution Language (BPEL) (as in Figure 1 1-6 on page 158) or directly 
executable Business Process Modeling Notation (BPMN). See Chapter 7, “The 
role of standards” on page 89, for information about the role of format standards. 
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Figure 1 1 -6 BP EL implementation of a business process 
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At this point, automated activities need to be bound to callable services, which 
should be done (as much as possible) in accordance with desired relationships 
between process targets and service targets in the EA model. 


11.4 Step 4: Manage 

The manage step is where running BPM artifacts are measured for real-time 
performance and where data is validated to show how (or not) the defined 
functional and non-functional requirements are being met. This step is the key 
feedback loop illustrated by the red arrow between operations and portfolio 
monitoring in Figure 1-5 on page 10 and is a critical part of the interaction 
between the project and portfolio optimization life cycles in the enterprise 
landscape. Figure 11-7 illustrates this step. 





Figure 11-7 Monitor, predict, and act 

Importantly, real-time performance monitoring also empowers business end 
users to customize their experience (their business space) and manage KPIs 
and alerts based on changing business conditions. Contrary to what was the 
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case with (EA) enterprise planning artifacts, breakages or unexpected behavior 
in (BPM) operational processes can and will have immediate and negative 
business effect. 

Figure 11-8 further illustrates dashboards that help manage real-time process 
performance. 



Figure 1 1-8 Manage real-time process performance 


Table 1 1 -4 lists activities for the experience step. For more information, see BPM 
Solution Implementation Guide, REDP-4543. 


Table 1 1-4 Experience step activities 


Detailed Activities 

Role 

Deliverable 

(Optional) Empower business users to customize the 

Solution 

Configured in 

user experience: 

administrator and 

Business Space 

For collaborative business environments, configure 
role-based access in Business Space to enable 
business users to create, modify, improve upon, or 
personalize their BPM experience as business needs 
evolve. 

Customer-specific templates can replace templates 
that are ready for immediate use in the Business 
Space to simplify the creation of new spaces by users. 
This step is optional and not appropriate for business 
environments where the user environment is locked 
down and strictly regulated. 

business users 
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Detailed Activities 

Role 

Deliverable 

Optimize work assignments: 

An ongoing process of looking across the allocation of 
human tasks among organizational team members to 
shuffle work-around and respond to changing 
business conditions. 

Insight into work allocation can be achieved through a 
combination of team-based task views and monitor 
visualizations that can optimization decisions. 

Efforts to optimize work can be performed by a 
business user playing a supervisory role or as part of 
an empowered peer organizational structure. 

Business users and 
business leaders 


Govern change: 

Store and manage artifacts in a common repository to 
preserve traceability across tools and changes being 
made. 

Identify key stakeholders and institute a review 
process to govern change. 

Business users, 
business leaders, 
and 

IT developers 
(setup) 


Manage real-time business performance: 

Monitoring of the process provides insight into types 
of business transactions, identifies bottlenecks within 
the process, and allows drill-down from high-level 
business views to individual processes of interest. 

A typical performance management dashboard will 
have a set of KPIs that measure process performance 
against business targets, durations for key activities 
(for example, human steps) in the process, and 
dimensional analysis that allows for analysis by 
different business attributes of the process (such as 
channels, customer type, and so on). 

Dashboards will also typically incorporate some 
drill-down enabling users to locate business 
transactions of interest. Drill-down can start from 
high-level views or data analysis, to visualizing a 
process flow, to locating individual human tasks in the 
process and taking action to reallocate work. 

Business users and 
business leaders 


Manage KPIs and alerts based on changing business 
conditions: 

As the business environment evolves, KPI 
performance targets and critical situations requiring 
user attention will change. 

Users can use KPI and alert management to create 
new performance targets as needed from a web 
interface without IT involvement and can customize 
their process visualization accordingly. 

Business users and 
business leaders 
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Detailed Activities 

Role 

Deliverable 

Take corrective action against process instances: 

Administrators can locate individual process 
instances or failed process transactions, correct the 
in-flight transaction, and continue the process through 
to completion. 

Dynamic changes to a specific process instance 
include modifying business data for the process 
instance, skipping steps, or redoing steps within the 
instance. 

Any processes that failed due to transient IT 
conditions (for example, network failure) or bad data 
can be corrected and resubmitted for processing, with 
the net effect that no transaction is lost. 

Solution 

administrator 
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12 


Linking EA and BPM 
artifacts 


Throughout this book, we have presented that business process management 
(BPM) and Enterprise Architecture (EA) are synergistic and that BPM and EA 
artifacts should be linked and changes coordinated across the domain 
boundaries. In this chapter, we show how to achieve this type of linking in 
practice. 

As explained in Chapter 7, “The role of standards” on page 89, we consider 
OSLC the future standard for semantically meaningful links. Having said that, the 
OSLC specifications are still evolving and few modeling products have 
implemented them at this time. Consequently, we have chosen to illustrate the 
practicalities of linking BPM and EA artifacts through simple URL-based links, 
rather than more semantically rich OSLC links. 

It is important to understand that links between BPM and EA artifacts can be 
initiated in either direction, as we will illustrate from the different scenarios 
described in Chapter 13, “Four select collaboration scenarios” on page 173. 
Ideally, any established link must be bidirectionally visible, independently of 
which end of the link was the originator. OSLC links fulfill that requirement, but 
simple URL-based links do not. Therefore, when using simple URL-based links, 
you need to either establish two links (one in each direction) or take care to 
establish the single link in the most useful direction (typically from BPM to EA). 
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Furthermore, it is important to understand that although our examples in this 
chapter are all process-to-process links, the true nature of coordination between 
BPM and EA is many-to-many linking as shown in Figure 6-2 on page 87. Many 
different EA targets can all apply to the same BPM artifact, and many different 
BPM artifacts can be guided and governed by the same EA target. 


12.1 Establishing a link 

To establish a link, you need to fulfill the following requirements: 

► Access to the artifact that is the origin of the link (usually in a local tool). 

► Ability for the target of the link to be accessed using HTTP. How this is 
accomplished and whether the target is natively HTTP accessible or needs to 
be published first depends on the exact tools and repositories involved. 

► A stable URL at which the target of the link can be accessed. How such a 
stable URL is acquired depends on the exact tools and repositories involved. 

The requirement that the target URL be stable is critical; the link needs to 

continue to function even when new versions of the target are created. 

Figure 12-1 on page 165 shows what establishing a link from an EA artifact to a 

BPM artifact might look like in an EA tool. We use “localhost” in the URL because 

in our demo environment, the target web server is hosted on the local machine. 
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Figure 12-2 and Figure 12-3 on page 167 show a slightly different example for a 
BPM tool. 



Figure 12-2 Add Link dialog box in a BPM tool 
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12.2 Following a link 


Having established some links, we can look for a linked artifact. Figure 12-4 
shows an example from an EA tool where the linked artifact is marked by a small 
red box. 
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The linked BPM artifact is accessible either by clicking the symbol shape or by 
navigating from a property pane, as shown in Figure 12-5. 



Figure 12-5 Property pane with navigation URL 
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Figure 12-6 and Figure 12-7 on page 171 show a slightly different example for a 
BPM tool that provides navigation with an attribute pane. 
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Figure 12-7 Viewing navigation link attributes 


In both examples, when the link is activated, one of two things happens. Either 
the target artifact opens in a new browser window, or the target artifact shows in 
an embedded browser window in the tool where the link was activated. 
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Four select collaboration 
scenarios 


We have already explained in general terms how business process management 
(BPM) practitioners and enterprise architecture practitioners need to collaborate. 
There are different scenarios where such collaboration can play out in practice. 
In this chapter, we have selected three such scenarios that all use linking to 
enable collaboration: 

► EA governance 

► BPM insight 

► BPM exception 

Each of the scenarios has different variants, some of which are important enough 
to call out explicitly in our description. These scenarios are not an exhaustive list 
yet are representative of the typical situations found in mature organizations that 
understand the synergistic nature of BPM and EA. Although we continue to use 
JKHL Enterprises as our example and context, the scenario patterns that we 
define in this chapter are general and can be applied to any enterprise. 
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13.1 EA governance 


In this scenario, an incremental change to the EA blueprints impacts the portfolio 
of BPM processes, and EA governance needs to be applied to make the 
changed targets visible and to decide how to comply with them (if possible). The 
EA governance scenario includes the following steps: 

► la: Adjust process portfolio goals and constraints. 

► 1 b: Identify process portfolio impact and initiate change projects. 

► 1c: Monitor architectural compliance of changes to the process portfolio. 

Figure 13-1 illustrates where the related collaboration points are placed on the 
enterprise landscape for a brown field environment with existing BPM artifacts. 
For special concerns in green field environments with few or no existing BPM 
artifacts, see 13.1.1, “Cloning of EA artifacts” on page 178. 



Step 1b, identifying the scope of impact on the portfolio, is absolutely critical. We 
must identify, in collaboration with the process owners and portfolio managers, 
which operational processes that are within scope of the changed or new EA 
targets before we can act appropriately. 
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If the change is to an existing EA artifact that is already linked to relevant BPM 
artifacts, then identifying the scope of impact is easy. Use the EA impact analysis 
capability and follow the links to the BPM artifacts that are impacted. In our JKHL 
Enterprises example, we can look up the process hierarchy, which is shown in 
Figure 13-2. 
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We can identify processes that are potentially impacted, namely those linked to 
the changed EA model element (in this case, the element labeled with a red box). 
Using the associated link, we can navigate to the BPM model (Figure 13-3) to 
validate whether in fact the process needs to change. 
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Figure 13-3 Original BPM model 


Any actual changes to the BPM model must be done within the BPM modeling 
tools, usually in the context of a new (full life cycle) change project. If links do not 
exist, the EA practitioner and the BPM process portfolio manager can collaborate 
to identify the relevant set of operational processes manually, and subsequently 
establish the relevant links for future use. 

Note that this does not mean that all such operational processes are necessarily 
modeled in any form of detail. All it means is that we need placeholder artifacts in 
the BPM portfolio that can link to the EA target for visibility and later guidance of 
initiated solution delivery projects. 

In some cases, we might also identify collaboratively that there is no current 
operational process that adequately supports the EA target, so one must be 
added to the operational portfolio. In the JKHL Enterprises example, we realized, 
as described in Chapter 1 1 , “BPM applied” on page 147, that we must add a new 
subprocess to the current online banking process. This subprocess extracts 
account data from an external SAP system, as shown in Figure 13-4 on 
page 177. 
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Figure 13-4 New subprocess extracting account data from an external SAP system 


Any new BPM artifact must be linked to the originating EA target. See 
Chapter 12, “Linking EA and BPM artifacts” on page 163, for details about how to 
establish links. 

We have already mentioned that many changes in the solution delivery domain 
are appropriately executed in project mode. Established organizations will use 
tools to track changes and related change projects across tools and artifact 
domains. Although the scope of this book does not cover change management in 
depth, we do want to suggest that it can be advantageous to document desired 
changes as change requests within the EA domain and link them as applicable to 
change projects being executed within solution delivery. Figure 13-5 on page 178 
shows an example. 


Chapter 1 3. Four select collaboration scenarios 


177 





Figure 13-5 EA tool with Change Request 


When the changes are logged in the EA model, they are tracked and form part of 
the foundation for EA transition planning, road maps, and so on. 

13.1.1 Cloning of EA artifacts 

If the BPM discipline in an organization is mostly green field, no existing BPM 
artifacts are at hand, and the EA discipline at the same time is well developed, 
the EA governance processes described previously pose particular challenges. 
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An effective and consistent way of accelerating the design of new BPM 
processes is needed. 

In earlier parts of this book, we explained the concept of cloning. Cloning is used 
when you want to use one thing as the starting point for another completely 
different thing, such as using a clone of an EA process blueprint as the starting 
point for a new BPM process model. 

Such cloning capabilities, based on standardized resource format standards 
such as Business Process Modeling Notation (BPMN) 2.0, are advantageous to 
have as part of a BPM and EA collaboration arsenal. We have to caution once 
again that the resulting BPM artifact is different from the EA original. It has its 
own life cycle and different semantics than the EA process blueprint. (See 
Chapter 6, “Stop copying; start linking” on page 83, for details.) One reason to be 
cautious is that by reflex many people think of and ask for export/import when 
they talk about BPM and EA “integration”. There are several issues with this line 
of thinking: 

► The proper relationship between BPM and EA is synergistic collaboration and 
coordination, not export/import “integration.” 

► Export/import produces a non-linked copy. A clone should have a different 
identity, its own life cycle, and be linked to the original source for future 
visibility and change management. 

► Cloning is the exception and should only be used once per artifact in a green 
field situation. The normal situation is existing artifacts with established cross 
domain links. 

Cloning, when properly applied, is a valuable accelerator. When it is misused 
beyond first time green field scenarios, cloning (or even worse copying) leads to 
manageability issues. 


13.2 BPM insight 

In this scenario, a BPM activity provides insight that may affect the enterprise 

architecture. This can happen in two ways: 

► Upon completion, a project wants to share experiences with using a set of EA 
targets and wants to provide suggestions for improvements. 

► Through monitoring of operational process efficiency, a systemic performance 
issue is identified. The issue could be solved by applying appropriate 
standards and patterns to all issue processes. 
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Because these two situations are sufficiently different and lead to somewhat 
different collaborations, we address them separately. 


13.2.1 Project experience 

When a project completes, it is important to not only consolidate the newly 
delivered assets into the asset portfolio, but also to harvest experience gained 
from using applicable EA targets. Such experience can either be in the form of 
how well the targets worked in the project and how close the project came to 
meeting the targets, or it can be more fundamental in terms of explicitly 
suggested additions or changes to the EA model. In this section, we focus on the 
latter, the case where project experience leads to suggesting changes to the EA 
model. This scenario includes the following steps: 

► 2a: Report on project experiences. 

► 2b: Discuss with the process portfolio managers whether the project 
experiences represent important insight and should lead to suggested EA 
model changes (project experiences might not be representative or might be 
contrary to process portfolio goals). 

► 2c: Collaborate with the EA practitioners to assess the suggested changes, 
both in terms of architectural compliance reporting and in terms of 
adjustments to EA blueprints and principles. 
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Figure 13-6 illustrates where the related collaboration points are placed on the 
enterprise landscape. 



Practically, step 2c is typically the step that needs formal collaboration and review 
procedures, and is also the step that needs to use linking between BPM and EA 
artifacts. 

If the BPM artifacts from the project are already linked to existing and applicable 
EA artifacts, then identifying the scope of potential impact on the EA model is 
easy. Simply enumerate those EA artifacts that are linked to the BPM artifacts 
that were the origin of the project insight. 

If links do not exist, the EA practitioner, the BPM process portfolio manager, and 
the BPM project representative need to collaborate to identify the relevant set of 
EA artifacts manually. If such EA artifacts do not exist, the EA practitioner needs 
to at a minimum create placeholders that can subsequently be linked to the (now) 
related BPM artifacts. 

Note that while we have talked about this scenario as though project insight is 
only “reported” when the project completes, depending on the collaborative 
processes in a particular enterprise, new insight can be processed at any point 
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during the project life cycle. The steps and concerns will be the same as 
described for the end-of-project situation. 

13.2.2 Systemic issue identified through operational monitoring 

We have already explained how continuous monitoring and feedback is a key 
component of a well-driven BPM initiative. For this reason, BPM insight can be 
gained not only from projects, but also from analyzing monitoring results. For 
example, through monitoring of operational process efficiency, a systemic 
performance issue is identified that can be solved by applying a set of standards 
and patterns to all issue processes. 

Admittedly, it could be tempting to just fix the problem from a solution perspective 
instead of collaborating with the EA practitioners as suggested, but doing that is 
not the optimal choice. Because this is a systemic issue and likely to occur again 
in future processes until better enterprise guidance is provided, a better 
approach is to collaborate with the EA function with the objective of establishing 
appropriate EA standards and blueprints for (all) business processes, as 
illustrated on the enterprise landscape in Figure 13-7. 
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If applicable EA standards and blueprints exist, either these are not working and 
need to be updated, or the EA governance processes are not working and need 
to be strengthened. See 13.1 , “EA governance” on page 174, for more details on 
strengthening EA governance. 


13.3 BPM exception 

In this scenario, a BPM project cannot comply with defined EA targets. Whether the 
exact root cause is lack of time, unsustainable cost, lack of capabilities available, or 
something else, in all cases an exception request needs to be processed. 

Although the project on its own cannot comply with the EA targets, this might be 
a case where it is so important to the enterprise to comply with the targets that 
additional aid from outside the project can be provided or the project parameters 
can be changed another way. The only way to assess this situation appropriately 
is to process the change request with relevant stakeholders. See 3.3, “Integrated 
strategic planning” on page 41 , for more details about exception handling. 

Figure 13-8 illustrates a major BPM exception that is requested when it is time for 
deployment. The exception needs to be assessed by and discussed with the EA 
function. 



Figure 13-8 Processing a BPM exception 
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It is preferable to identify and process an exception request as early as possible 
in the life cycle of a project. The earlier a decision is made, the less costly any 
necessary adjustments will be. Note that it often can be difficult to decide, when 
compliance with the EA targets cannot be met, whether this is a case of an 
exception or the case of targets that need to be adjusted based on project 
insight, as explained in 13.2, “BPM insight” on page 179. The only way to 
determine the proper course of action is to collaborate with the EA function as 
suggested in Figure 13-8. 

In our JKHL Enterprises example, the daughter bank in Germany is an 
acquisition. That bank currently uses SAP and will do so for the next two years. 
However, because of the acquisition, SAP will eventually be replaced and for cost 
and risk reasons no modifications or enhancements to the SAP system will be 
allowed in the meantime. Consequently, the online banking system in the 
German daughter bank cannot comply with the EA target that includes up-sell 
activities in the transactional processes and needs an exception for the next two 
years. The exception is logged in the EA model, and monitoring of EA 
compliance resumes after the exception period has expired. 

Once again, this example illustrates how critically important the links between 
BPM and EA artifacts are to the desired collaboration between the BPM and EA 
practitioners. Without those links in place, the BPM practitioners cannot identify 
the need for requesting an exception, and the EA practitioners cannot 
continuously monitor architectural compliance. 
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